Proposed Phobos equivalent of wcswidth()

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 15 18:37:14 UTC 2018


On Mon, Jan 15, 2018 at 06:20:16PM +0000, Jack Stouffer via Digitalmars-d wrote:
> On Monday, 15 January 2018 at 17:32:40 UTC, H. S. Teoh wrote:
> > On Mon, Jan 15, 2018 at 02:14:56PM +0000, Simen Kjærås via Digitalmars-d
> > wrote:
> > > On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote:
> > > > std.utf.displayWidth
> > > 
> > > +1
> > [...]
> > 
> > Why std.utf rather than std.uni, though?
> 
> The way I understand it is that std.uni is (supposed to be) for
> functions on individual unicode units (be they code units/points or
> graphemes) and std.utf is for functions which handle operating on
> unicode strings.

Are you sure?  I thought std.utf was specifically dealing with UTF-*
encodings, i.e., code units and conversions to/from code points, and
std.uni was supposed to be for implementing Unicode algorithms and
Unicode compliance in general, i.e., stuff that works at the code point
level.


> Obviously there are exceptions. I think "they" put graphemeStride in
> std.uni because Grapheme was defined there and it seemed reasonable at
> the time.  But, generally I think utf stuff should go into std.utf.

But displayWidth isn't really directly related to UTF (i.e., the
encoding of Unicode code points).  It seems to me to be more to do with
processing Unicode in general, though, granted, the optimizations I
implemented are kinda in a grey zone between dealing with Unicode proper
(i.e., with code points) vs. working with code units.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney


More information about the Digitalmars-d mailing list