On Monday, 1 November 2021 at 08:45:07 UTC, Paolo Invernizzi wrote:
> On Monday, 1 November 2021 at 00:59:49 UTC, Adam Ruppe wrote:
>> On Monday, 1 November 2021 at 00:05:30 UTC, Andrei Alexandrescu wrote:
>>> while we were wringing our hands about breaking the behavior for like a dozen users.
>>
>> If you agree there are only like a dozen users, why not just make the changes and be done with it? Why worry about preserving v1 behavior at all? (Worth noting you can always just download an old version too.)
>
> +1

+1
Might be a few people, but I wouldn't mind Phobos just having breaking changes (and a changelog entry for each).

1. In reality we can special case with static if (__VERSION__)

2. This is routine in the DUB universe, you can produce a new major tag with breaking changes, provide a changelog, and inside you can delete a dependency, add a dependency, rename, and it's quite good as users can depends on the earlier version. If anything, I think putting some of the stdlib as dub package (the barely used stuff) might help evolves the API and lessen the exposure (examples: std.uuid std.bigint std.getopt...).

3. I bet most of the commercial users usually pin the D compiler version they use.

On Monday, 1 November 2021 at 00:05:30 UTC, Andrei Alexandrescu wrote:
> On 10/31/21 2:37 PM, Johan wrote:
>> On Sunday, 31 October 2021 at 17:32:07 UTC, Andrei Alexandrescu wrote:
>>>
>>> I'd say if we get rid of autodecoding that would be a solid release attainable in good time. It would also provide a model for all future evolution - v3, v4, ...
>> 
>> Hi Andrei,
>>    Are you not worried about increasing the knowledge required to use and understand D? What I mean is: if the _standard_ library is going to be versioned, users will have to remember the differences between all versions of it.
>
> Thanks for asking.
>
> I have zero worries about that. Negative if at all possible.
>
> [...]
>
> There is stuff added to C++11, improved in C++14, and deprecated in C++17. And nobody bats an eye.
>
> Given the above and also the perennial stagnation the D library has been in, I'd say it's version or die.

OK. Just note that C++11,14,17 is a 3 year update schedule, whereas currently the D compiler releases at breakneck pace of 3 months. I really hope the versioned stdlib releases will not move at that pace.

> The fact that a solution turned out to be so simple is actually evidence that the community has been missing the point for years, instead of just working on the top priority.
>
>> I'm sorry to derail the topic of this thread, but rather than a discussion of how to implement the versioning, I would like to see a discussion first about what the user will see and how he is supposed to use it. I think the implementation of it is the easy part.
>
> I very strongly disagree.

Perhaps you misunderstood my point, but reading your mail I see we agree on most :) As you wrote a few sentences up, at least you agree that implementation is indeed easy ;-)

Just having clear examples of some code would really help paint the picture that indeed the future is bright with versioned stdlib.
Breakage can be OK, if done deliberately and in a 'nice' way for the user to deal with; and versioning deliberately prevents breakage.

>> Is the user expected to completely migrate to use std.v3, or should he use a mix of std.v1, std.v2, std.v3?
>
> Up to them.

This is a big statement. For me this means:
- v1 support is 'everlasting' and bugfixes will keep landing there too.
- v2, v3, v4 will contain _all_ functionality that v1 has, and version x may be somewhere halfway on the path between v1 behavior and end goal behavior (e.g. some functions still do autodecoding and others don't). Another path would be to only add to v2 the functions that have changed, and for functionality that did not change the user should keep using v1.

>> Will there be autodecoding functions in v3?
>
> Probably not. But there will be decoding functions in v3.

Removing the "auto" part sounds very good indeed.

-Johan

On Monday, 1 November 2021 at 04:44:34 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 1 November 2021 at 02:27:21 UTC, bachmeier wrote:
>> On Monday, 1 November 2021 at 00:05:30 UTC, Andrei Alexandrescu wrote:
>>
>>> Given the above and also the perennial stagnation the D library has been in, I'd say it's version or die.
>>
>> I have to admit that at times D feels like Common Lisp. A nice language for when it was designed, but now one that values stability over all else, at the expense of building on a good foundation. The death of Common Lisp was the standard. Something similar happened at some point for D but without standardization.
>
> No. The end of Lisp was parentheses and Haskell. The standard made it linger on for several decades beyond reason.

I'm not sure there's been "several decades beyond reason", since the standard came out only 27 years ago. The point I was trying to make is that the language was stagnant when I used it most heavily (maybe 2010-2012). It's useless trying to update pieces that are in the standard, and there was no process for updating the standard. The result was a boring language frozen in time. Matches up nicely with the low-hanging fruit Andrei listed.

> The std lib should be the bottom layer, and small, so you can keep it stable, efficient and provide targeted compiler optimizations.

This is an argument in favor of versioning. V1 can have all those properties, and subsequent versions can build on it.

On Monday, 1 November 2021 at 02:29:53 UTC, Andrei Alexandrescu wrote:
> On 10/31/21 10:27 PM, bachmeier wrote:
>> Always a false dichotomy where it's either a neverending stream of breaking changes or it's 100% stability.
>
> Versioning std will take us out of that rut.

And for the record, I think this will be a massive boost for the language if you can get enough people on board.

On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/8309
>
> Destroy!

Excellent idea. I think we should go for it.

I don't think this model mandates we have to keep v1 around forever. We might support it for a few years from v2 stabilisation and then drop it.

Some have asked why we cannot just move and break stuff. My opinion is that it would probably be okay if everyone would be using Phobos only directly. But many of the DUB packages are also going to depend on one or the other Phobos. Save for separately compiled binary libraries, they cannot be used together anymore if v1 and v2 don't interoperate.

On 2021-10-31 23:34, zjh wrote:
> The C++ `concept` is also very convenient. When writing constraints on a separate `T` type, there is no need to write an `if...` behind. With a little effort, users can feel comfortable.

The problem with C++ concepts is that they invent yet another language on the top of the three C++ already has in it. It is a massive mistake, though not big enough to destroy the language. C++ continues to be successful in spite of it, not because of it.

The right way is to express concepts within the current language and algebra, as D does.

On 2021-10-31 23:49, zjh wrote:
> We don't need to be better than `C++` in every aspect.

D needs to be as good or better than C++ at the things C++ is good at, and better than C++ at the things C++ is not good at.

On 2021-11-01 4:03, bauss wrote:
> On Sunday, 31 October 2021 at 17:32:07 UTC, Andrei Alexandrescu wrote:
>> (looking at the contributors since 2019 at https://github.com/dlang/phobos/graphs/contributors?from=2019-01-01&to=2021-10-31&type=c) berni44, n8sh, ibuclaw, MoonlightSentinel and other heavy-hitters. And of course Razvan, the maintainer.
>>
> 
> The opinion of contributors shouldn't be the only opinion that matters.
> 
> The opinion of long-term users of D in production etc. should be valued just as much.
> 
> I've been using D for about a decade now, but I've never contributed a lot other than minor things but I've definitely been all-around the standard library.
> 
> I can only imagine that's the case of a lot of other users.
> 
> Please don't discourage the opinion of long-term users of D.

Of course. My point has been taken out of context.

Versioning is a net positive for all users. The amount of work needed can vary drastically. That's all I was saying.

On 2021-11-01 6:48, Guillaume Piolat wrote:
> On Monday, 1 November 2021 at 08:45:07 UTC, Paolo Invernizzi wrote:
>> On Monday, 1 November 2021 at 00:59:49 UTC, Adam Ruppe wrote:
>>> On Monday, 1 November 2021 at 00:05:30 UTC, Andrei Alexandrescu wrote:
>>>> while we were wringing our hands about breaking the behavior for like a dozen users.
>>>
>>> If you agree there are only like a dozen users, why not just make the changes and be done with it? Why worry about preserving v1 behavior at all? (Worth noting you can always just download an old version too.)
>>
>> +1
> 
> +1
> Might be a few people, but I wouldn't mind Phobos just having breaking changes (and a changelog entry for each).

The whole "dozen users" has been a misunderstanding - there are users whose code depends on every little thing, different for different categories. It's not like any breakage no matter how large affects only a few users.

"No more autodecoding" is more than a change worth a changelog entry. Compounded with other changes it's just catastrophic. This is obvious and we oughtn't debate it.

> 1. In reality we can special case with static if (__VERSION__)

Which has worked well for no language, ever. Pushing versioning hell on users doesn't seem like a good way to go about things.

> 2. This is routine in the DUB universe, you can produce a new major tag with breaking changes, provide a changelog, and inside you can delete a dependency, add a dependency, rename, and it's quite good as users can depends on the earlier version. If anything, I think putting some of the stdlib as dub package (the barely used stuff) might help evolves the API and lessen the exposure (examples: std.uuid std.bigint std.getopt...).

I think the language's standard library is under different constraints than others.

> 3. I bet most of the commercial users usually pin the D compiler version they use.

Of course. And they all love a migration path.