Major performance problem with std.array.front()

[Andrei Alexandrescu]

On 3/9/14, 8:18 AM, Vladimir Panteleev wrote:
> 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.

It's just factual information with no drama attached (i.e. I'm not 
threatening to leave the language, just plainly explain I'll never 
approve that particular change).

That said a larger explanation is in order. There have been cases in the 
past when our community has worked itself in a froth over a non-issue 
and ultimately caused a language change imposed by "the faction that 
shouted the loudest". The "lazy" keyword and recently the "virtual" 
keyword come to mind as cases in which the language leadership has been 
essentially annoyed into making a change it didn't believe in.

I am all about listening to the community's needs and desires. But at 
some point there is a need to stick to one's guns in matters of judgment 
call. See e.g. https://d.puremagic.com/issues/show_bug.cgi?id=11837 for 
a very recent example in which reasonable people may disagree but at 
some point you can't choose both options.

What we now have works as intended. As I mentioned, there is quite a bit 
more evidence the design is useful to people, than detrimental. Unicode 
is all about code points. Code units are incidental to each encoding. 
The fact that we recognize code points at language and library level is, 
in my opinion, a Good Thing(tm).

I understand that doesn't reach the ninth level of Nirvana and there are 
still issues to work on, and issues where good-looking code is actually 
incorrect. But I think we're overall in good shape. A regression from 
that to code unit level would be very destructive. Even a clear slight 
improvement that breaks backward compatibility would be destructive.

So I wanted to limit the potential damage of this discussion. It is made 
only a lot more dangerous that Walter himself started it, something that 
others didn't fail to tune into. The sheer fact that we got to 
contemplate an unbelievably massive breakage on no other evidence than 
one misuse case and for the sake of possibly an illusory improvement - 
that's a sign we need to grow up. We can't go like this about changing 
the language and aim to play in the big leagues.

>> 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.

Sorry to disappoint.

> ---
>
> 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.

I think only the char -> dchar conversion works, and I can see arguments 
against it. Also comparison of char with dchar is dicey. But there are 
also cases in which it's legitimate to do that (e.g. assign ASCII chars 
etc) and this would be a breaking change.

One good way to think about breaking changes is "if this change were 
executed to perfection, how much would that improve the overall quality 
of D?" Because breakages _are_ "overall" - users don't care whether they 
come from this or the other part of the type system. Really puts things 
into perspective.

> 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.

Generally I think we should steer away from slight improvements of the 
language at the cost of breaking existing code. Instead, we must think 
of ways to improve the language without the breakage. You may want to 
pursue (bugzilla + pull request) adding the std.conv routines with the 
semantics you mentioned.


Andrei