On Thursday, 2 June 2016 at 07:21:28 UTC, Joakim wrote:
> On Thursday, 2 June 2016 at 06:53:49 UTC, poliklosio wrote:
>> (...)
>
> It has been noted many times that forum users are a small part of the D userbase, likely the ones who are the most interested in evolving the language and thus biased towards changes.  As a forum user myself, I'm in that group too and agree with Walter that D programmers should be guided by Phobos to explicitly declare what level of decoding they want, but this poll may not be representative of the wider userbase.
>
> We'll likely only find out what they think once we're a couple dmd releases into these changes, as Walter found when he submitted PRs for file/path code sometime back.

Its not representative but there is going to be at least some weak correlation between the forum and proffesional world. We are developers after all. Out of 16 proffesional users none selected "Please, don't break my code" option, which tells that there is some hope that a change wouldn't be that damaging. Of course further investigation would be needed to confirm that hypothesis. But at least we didn't prove that such investigation is a waste of time.

Also, on the issue of wanting/not wanting autodecoding as a feature (ignoring the code breakage issue) 0 out of 55 people actually want autodecoding. I think its improbable that most users outside the forum would have the opposite view. You would have at least some of this refrected in the poll.

So the poll does tell something, you just have to know how not to overinterpret the results. :)

On Thursday, 2 June 2016 at 04:42:49 UTC, Walter Bright wrote:
> Andrei is in favor of fixing Phobos so it does not depend on autodecode.

Putting the autodecode functions on a compiler switch (with -version) is the most straightforward way to achieve that.

We'd have a transition period where people can keep the existing behavior or throw the switch and get compile errors - with a dead-simple "just add .byCodePoint on this line" fix - to migrate their code.

Phobos would be fixed in a day. Everyone else would have up to a couple years to fix their code (which, again, is as simple as throwing a compiler switch and mechanically adding .byCodePoint* where the static asserts tell you to) as we work through the slow deprecation cycle.

But then, we'd have light at the end of the tunnel: after this deprecation cycle completes, we can kill hundreds of lines of confusing, worthless functions. Existing functions that don't work with ranges of chars will be able to without trouble. Newbies will never again ask "wtf" when they see string.whatever yielding dchar[].

* Or byGrapheme or .byCodeUnit or whatever if you want to take the time to actually fix the fundamental question of the code, but just slapping .byCodePoint in there reverts to the same behavior of autodecode.

> Interestingly, when I tried to remove autodecoding from path/file code a couple years ago, I received quite a bit of resistance. It seems there's been a tectonic shift in opinion on autodecode.

Quite a few of us were incompetent ignoramuses on the topic of Unicode years ago. That's where the autodecoding mistake came from: people smart enough to know UTF-8 from UTF-32, but not smart enough to know the real world application of Unicode.

It's one thing to make a mistake. Everyone does that sometimes, and nobody is born knowing complex issues. What matters is if you're willing to learn new information and correct your errors.

On 06/02/2016 09:34 AM, Adam D. Ruppe wrote:
> On Thursday, 2 June 2016 at 04:42:49 UTC, Walter Bright wrote:
>> Andrei is in favor of fixing Phobos so it does not depend on autodecode.
>
> Putting the autodecode functions on a compiler switch (with -version) is
> the most straightforward way to achieve that.
>
> We'd have a transition period where people can keep the existing
> behavior or throw the switch and get compile errors - with a dead-simple
> "just add .byCodePoint on this line" fix - to migrate their code.

That is not going to happen.

> It's one thing to make a mistake. Everyone does that sometimes, and
> nobody is born knowing complex issues. What matters is if you're willing
> to learn new information and correct your errors.

The real ticket out of this is RCStr. It solves a major problem in the language (compulsive GC) and also a minor occasional annoyance (autodecoding).


Andrei

On Thursday, 2 June 2016 at 14:29:28 UTC, Andrei Alexandrescu wrote:
>> It's one thing to make a mistake. Everyone does that sometimes, and
>> nobody is born knowing complex issues. What matters is if you're willing
>> to learn new information and correct your errors.
>
> The real ticket out of this is RCStr. It solves a major problem in the language (compulsive GC) and also a minor occasional annoyance (autodecoding).
>

You start to sound like a car salesman. I know nothing about RCStr, but I'm already starting to resent it.

On Thursday, 2 June 2016 at 13:34:18 UTC, Adam D. Ruppe wrote:
> On Thursday, 2 June 2016 at 04:42:49 UTC, Walter Bright wrote:
>> Andrei is in favor of fixing Phobos so it does not depend on autodecode.
>
> Putting the autodecode functions on a compiler switch (with -version) is the most straightforward way to achieve that.
>
> We'd have a transition period where people can keep the existing behavior or throw the switch and get compile errors - with a dead-simple "just add .byCodePoint on this line" fix - to migrate their code.
>
> Phobos would be fixed in a day. Everyone else would have up to a couple years to fix their code (which, again, is as simple as throwing a compiler switch and mechanically adding .byCodePoint* where the static asserts tell you to) as we work through the slow deprecation cycle.
>
> But then, we'd have light at the end of the tunnel: after this deprecation cycle completes, we can kill hundreds of lines of confusing, worthless functions. Existing functions that don't work with ranges of chars will be able to without trouble. Newbies will never again ask "wtf" when they see string.whatever yielding dchar[].
>
> * Or byGrapheme or .byCodeUnit or whatever if you want to take the time to actually fix the fundamental question of the code, but just slapping .byCodePoint in there reverts to the same behavior of autodecode.
>

I would love to have a compiler switch and finally be able to rid my code of auto decoding [1], once and for all - and get a free performance boost. There's so much talk about code that _might_ break, when we don't even know how much code would actually break. It's absurd, we remain inert out of fear of the unknown, while it would be pretty easy to just test it and find out (std.path is actually a precedence). And it wouldn't even be a breaking change in the sense that you cannot go on developing with D's latest version because you're stuck with a stone age version of dmd forever.

Much in the same vein, I don't know, if we should make the question of auto decode dependent on RCString. This will take at least another few months of bikeshedding, while what we need to do is get rid (or start to get rid) of auto decode right now - and maybe this process will teach us something that will later be useful when implementing RCString.

[1] As I already mentioned here
http://forum.dlang.org/post/yzeiqvphrqdcmaxaspvx@forum.dlang.org

[snip]

On Thu, Jun 02, 2016 at 02:44:21PM +0000, deadalnix via Digitalmars-d wrote:
> On Thursday, 2 June 2016 at 14:29:28 UTC, Andrei Alexandrescu wrote:
> > > It's one thing to make a mistake. Everyone does that sometimes, and nobody is born knowing complex issues. What matters is if you're willing to learn new information and correct your errors.
> > 
> > The real ticket out of this is RCStr. It solves a major problem in
> > the language (compulsive GC) and also a minor occasional annoyance
> > (autodecoding).
> > 
> 
> You start to sound like a car salesman. I know nothing about RCStr, but I'm already starting to resent it.

Same here. It's starting to sound like some unproven newfangled contraption designed to please the GC-phobic crowd who believe that RC is the answer to life, the universe, and everything, and who may not actually adopt D even after we've broken our backs bending over backwards for them.  (And with a subject like "our sister", this RCStr business does not sound very appealing at all.)  Whatever happened to improving *current* string handling for *current* users?

It's making forking Phobos look like a less distant possibility than I had anticipated. :-(


T

-- 
People say I'm arrogant, and I'm proud of it.

On 06/02/2016 10:44 AM, deadalnix wrote:
> On Thursday, 2 June 2016 at 14:29:28 UTC, Andrei Alexandrescu wrote:
>>> It's one thing to make a mistake. Everyone does that sometimes, and
>>> nobody is born knowing complex issues. What matters is if you're willing
>>> to learn new information and correct your errors.
>>
>> The real ticket out of this is RCStr. It solves a major problem in the
>> language (compulsive GC) and also a minor occasional annoyance
>> (autodecoding).
>>
>
> You start to sound like a car salesman.

I assume that means overselling or false advertising. Where do either of these happen? -- Andrei

On Thursday, 2 June 2016 at 15:03:34 UTC, Andrei Alexandrescu wrote:
>> You start to sound like a car salesman.
>
> I assume that means overselling or false advertising. Where do either of these happen? -- Andrei

For SDC for instance, autodecode is a problem (in fact, it is the very reason I abandoned making the lexer usable as a standalone) while RCStr would not help one bit as string are pretty much never manipulated directly anywhere.

More generally, using RCStr is at best sidestepping the issue rather than solving it.

On the GC side of the issue, I think there are also overstatements.

On Thursday, June 02, 2016 10:29:28 Andrei Alexandrescu via Digitalmars-d wrote:
> The real ticket out of this is RCStr. It solves a major problem in the
> language (compulsive GC) and also a minor occasional annoyance
> (autodecoding).

Unless we're outright getting rid of string, char[], wstring, etc., RCStr clearly doesn't solve the auto-decoding problem. It will allow a lot of code to sidestep it, but the existing types will continue to exist and be used and have to deal with auto-decoding. And every function that works on strings that cares about efficiency is going to have to continue to special case strings to avoid auto-decoding.

- Jonathan M Davis

On 06/02/2016 11:03 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jun 02, 2016 at 02:44:21PM +0000, deadalnix via Digitalmars-d wrote:
>> On Thursday, 2 June 2016 at 14:29:28 UTC, Andrei Alexandrescu wrote:
>>>> It's one thing to make a mistake. Everyone does that sometimes,
>>>> and nobody is born knowing complex issues. What matters is if
>>>> you're willing to learn new information and correct your errors.
>>>
>>> The real ticket out of this is RCStr. It solves a major problem in
>>> the language (compulsive GC) and also a minor occasional annoyance
>>> (autodecoding).
>>>
>>
>> You start to sound like a car salesman. I know nothing about RCStr,
>> but I'm already starting to resent it.
>
> Same here. It's starting to sound like some unproven newfangled
> contraption designed to please the GC-phobic crowd who believe that RC
> is the answer to life, the universe, and everything, and who may not
> actually adopt D even after we've broken our backs bending over
> backwards for them.

I'm sorry, this is completely ridiculous. What is unproven? Reference counting is a long-standing success story for string handling. I'm using it because it's good, not to woo users.

> (And with a subject like "our sister", this RCStr
> business does not sound very appealing at all.)

I'm glad this is mentioned as one of the issues with RCStr.

> Whatever happened to
> improving *current* string handling for *current* users?

RCStr will improve string handling for current users.

> It's making forking Phobos look like a less distant possibility than I
> had anticipated. :-(

So you'd fork Phobos because... it adds a good string type?


Andrei