Major performance problem with std.array.front()

Vladimir Panteleev vladimir at thecybershadow.net
Sun Mar 9 08:18:53 PDT 2014


On Sunday, 9 March 2014 at 05:10:26 UTC, Andrei Alexandrescu 
wrote:
> On 3/8/14, 8:24 PM, Vladimir Panteleev wrote:
>> On Sunday, 9 March 2014 at 04:18:15 UTC, Andrei Alexandrescu 
>> wrote:
>>> What exactly is the consensus? From your wiki page I see "One 
>>> of the
>>> proposals in the thread is to switch the iteration type of 
>>> string
>>> ranges from dchar to the string's character type."
>>>
>>> I can tell you straight out: That will not happen for as long 
>>> as I'm
>>> working on D.
>>
>> Why?
>
> From the cycle "going in circles": because I think the breakage 
> is way too large compared to the alleged improvement.

All right. I was wondering if there was something more 
fundamental behind such an ultimatum.

> In fact I believe that that design is inferior to the current 
> one regardless.

I was hoping we could come to an agreement at least on this point.

---

BTW, a thought struck me while thinking about the problem 
yesterday.

char and dchar should not be implicitly convertible between one 
another, or comparable to the other.

void main()
{
     string s = "Привет";
     foreach (c; s)
         assert(c != 'Ñ');
}

Instead, std.conv.to should allow converting between character 
types, iff they represent one whole code point and fit into the 
destination type, and throw an exception otherwise (similar to 
how it deals with integer overflow). Char literals should be 
special-cased by the compiler to implicitly convert to any 
sufficiently large type.

This would break more[1] code, but it would avoid the silent 
failures of the earlier proposal.

[1] I went through my own larger programs. I actually couldn't 
find any uses of dchar which would be impacted by such a 
hypothetical change.


More information about the Digitalmars-d mailing list