Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Why are control characters treated as zero-width for strings? #6

Open
@typesanitizer

Description

@typesanitizer

From thedocs:

fn width<'a>(&'a self) -> usize
Returns the string's displayed width in columns.
Control characters are treated as having zero width.

(Ignore '\0' for the points below as it has special treatment.)

This seems inconsistent with the behaviour for individualchars, whereNone is returned in case you have a control character. For consistency, I would expect (A) for a string, if any character has a width ofNone, the result should have widthNone XOR (B) control characters always have widthSome(0).

IIUC, the second option hasn't been taken for consistency withwcwidth, which returns-1 for control characters. However, not taking the first option can lead to non-intuitive behaviour that can go by unnoticed.
E.g. if the code has LF/TAB/DEL in it, then you can get an answer that doesn't make much sense.

Moreover, this violates an embedding law that one might expect to hold:width(format!("{}", c)) == width(c) (because it doesn't even type-check).

What is the reasoning behind the current behaviour?

P.S. I'm not asking for the library's behaviour to be changed. I'm writing a Haskell implementation and ran into this while looking at the test cases. My library follows (A) because it seemed like the right choice, so I wanted to know why you didn't pick (A).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp