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