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.

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.
Let's simply assume we have std.v2 without autodecoding, and std.v3 with less GC and less exception throwing. What kind of code would be 'hit' by this, and what would the new code look like? Is the user expected to completely migrate to use std.v3, or should he use a mix of std.v1, std.v2, std.v3? Will there be autodecoding functions in v3? (perhaps with UTF postfix of function name? Or is there no support and will the user have to implement it himself?) What about the old versions of functions that return GC'd data, or used to throw exceptions? Is the whole of std.v1 going to be deprecated at some point?
I think it'd be nice if there are a number of code examples worked out, showing what things are supposed to look like in a world with versioned standard library.

regards,
  Johan

On Sunday, 31 October 2021 at 17:32:07 UTC, Andrei Alexandrescu wrote:
> The problem with forum discussions is that folks without a stake get to envision things that others are to work on. (I don't know what github used IDs various folks have, so I'm saying this in general.) The most important is the take of folks who have a stake in it and a track record, such as (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.

Forgive me if I'm misinterpreting this, but this reads to me as "If you don't contribute to the core language your views are not important."

A sign of a potential echo-chamber in the higher parts of the language's hierarchy. Quite disturbing.

Somewhat relevant, a discussion about another survey a few years back, with the comment "Yes, leadership ignored it [the survey] almost completely.": https://forum.dlang.org/post/mfuubicfkfwgwwioltjp@forum.dlang.org

/melodrama

With an approach like this, wouldn't Phobos eventually end up as some kind of Frankenstein's code base? A huge blob of code full of historical baggage simply in the name of avoiding the word "breaking change"?

On Sunday, 31 October 2021 at 18:37:04 UTC, 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.
>
> 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.
> Let's simply assume we have std.v2 without autodecoding, and std.v3 with less GC and less exception throwing. What kind of code would be 'hit' by this, and what would the new code look like? Is the user expected to completely migrate to use std.v3, or should he use a mix of std.v1, std.v2, std.v3? Will there be autodecoding functions in v3? (perhaps with UTF postfix of function name? Or is there no support and will the user have to implement it himself?) What about the old versions of functions that return GC'd data, or used to throw exceptions? Is the whole of std.v1 going to be deprecated at some point?
> I think it'd be nice if there are a number of code examples worked out, showing what things are supposed to look like in a world with versioned standard library.
>
> regards,
>   Johan

Well, you're right in a sense. But I think this is more of a pragmatic question rather than structural / pedagogical.

We don't have the manpower to shift std in something other than doing it in small steps. So you have to make a choice. Small incremental changes vs bigger. And that choice can't be made "by itself" ie it depends on other things.

The best thing would probably be to keep std and make bigger changes. But then again, how to deal with breaking changes etc.

On Sunday, 31 October 2021 at 19:13:57 UTC, SealabJaster wrote:
> Somewhat relevant, a discussion about another survey a few years back, with the comment "Yes, leadership ignored it [the

COVID's messed up my sense of time (and ability to read) it seems. That was only about a year ago >;3

On Sunday, 31 October 2021 at 19:14:11 UTC, Imperatorn wrote:
> Well, you're right in a sense. But I think this is more of a pragmatic question rather than structural / pedagogical.

I think people kinda have lost what a standard library is supposed to be. There are two sensible viewpoints in my view:

1. The standard library is covering functionality all programs need, to save double work.

2. The standard library is covering those features that the language designers wanted to add to the language, but discovered they could do in a library instead.

But bloated standard libraries like those of Python have mixed this up with application level libraries. Which kinda works for Python, as it is a scripting language. I think the success of Python has made people copy this model…

In my view a standard library should be specced as an architecture of interfaces, then implemented, not evolve as an implementation exercise.

So, Andrei's perspective here is wrong. A standard library is not about who implements it. It is about speccing an architecture and feature set that is solid and tight, then open up for competing implementations (which is a «vendor issue»).

A sure sign of bloat is if there are numerous functions in a standard library that are not used much. C++ provides a few examples of ill-conceived extensions… For a small language this is even more important; less usage means more flaws/bugs, which in turn cannot be fixed because in a standard library bugs become features as existing programs may depend on them.

On Sunday, 31 October 2021 at 19:13:57 UTC, SealabJaster wrote:
[...]
> Forgive me if I'm misinterpreting this, but this reads to me as "If you don't contribute to the core language your views are not important."
>
> A sign of a potential echo-chamber in the higher parts of the language's hierarchy. Quite disturbing.
[...]

Having been around in the forums for a good number of years, I can say that Andrei's stance probably came from the history of the forum where every so often, somebody new barges in and tells everyone what we're doing wrong and their opinions about how things ought to be done instead.  Unfortunately, for all the time and energy spent in telling volunteers what to do with their spare time (rather presumptuous, if you'll allow me to say), after a period of time it becomes clear that said individual is not interested in actually investing the effort to make his vision of what ought to be done a reality.  After some time, such people either peter out and fade into the sidelines, or leave in a huff. After seeing several rounds of this, one can hardly help rolling one's eyes when the next precocious newcomer shows up with a bunch of opinions about why everybody else is wrong and what they should be doing instead.

Now, I'm not saying that what we've been doing is perfect and cannot be criticized -- there are definitely a lot of areas that need improvement.  And certainly none of us, Andrei included, is infallible, no matter how convinced we are that our way is the best.  So there's definitely a need to listen to users who often have a legitimate cause to complain.  But it certainly does not leave a good taste in the mouth when somebody comes and orders volunteers around as if they were employees, yet at the same time is reluctant to lift a finger to actually help out.  After witnessing what we did in the history of the forum, it's very tempting to just reach for the delete button when yet another message gets posted to the forum about how wrong we are and how right they are from someone who hasn't proven their willingness to actually contribute -- even if they do have a legitimate cause of complaint.

(P.S. I'm speaking in general, this is not directed at anyone in particular. Just in case something gets lost in translation/on the wire here.)


--T

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.

I've been to CppCon 2021 all of last week. There are as exoected commonalities and differences between the languages and the communities. But one thing is absolutely tremendous - C++ is evolving, FAST, and everybody loves every minute of it.

Having also been with the language during The C++ Winter (2000-2005) I can tell that stagnation is absolutely the worst thing that can happen to a language. Everybody was thinking that the C++98 standard needs to be given time to "settle", the standards committee was in a self-congratulatory and utterly unproductive rut, and the language was dying. I'm talking literally - the committee meetings and conferences were the same aging people! That all changed radically when Herb Sutter took the reins. Now young folks are flocking to C++ in droves.

C++ is adding a ton of features and library amenities on top of a much less powerful and weaker basis than D - e.g. namespaces and lookup are a joke by comparison. C++11, C++14, C++17, C++20, and now C++23 are rolling by while we were wringing our hands about breaking the behavior for like a dozen users.

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.

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.

There have been discussions about how to improve phobos. There are things many agree:

- get rid of autodecoding
- reduce gratuitous use of the GC
- improve safety
- be less liberal with throwing
- get rid of a lot of clowny support for enums a la WhateverSomethingOf
- improve the range interface

Then there's a long tail of desirable things, where everybody could add their own.

These have been discussed for literal years. And whenever someone said "X would be so much nicer", someone else would say "but that would break compatibility" and that would be the end of it.

NO LONGER.

> Let's simply assume we have std.v2 without autodecoding, and std.v3 with less GC and less exception throwing. What kind of code would be 'hit' by this, and what would the new code look like?

It's all about lookup and D's no-hijacking stance that we bragged for years about, yet didn't quite leverage yet.

Code using std.xyz will look things up there. Code using std.v2.xyz will look things up there. And so on. Named, static, local, etc. imports will allow users to resolve ambiguities during migration.

I assume subtleties and details will come forward but I see them part of the process rather than discouraging deterrents. The current years-long stagnation is the deterrent.

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

C++ has a similar mechanism with std::tr1 and std::tr2. I think it got abandoned, as there's no std::tr3. I speculate poor lookup rules and isolation are part of the reason.

> Will there be autodecoding functions in v3?

Probably not. But there will be decoding functions in v3.

> (perhaps with UTF postfix of function name?

I think it won't be in the function as much as the range - by!char, by!dchar etc.

> Or is there no support and will the user have to implement it himself?)

I think there will be UTF support in all versions.

> What about the old versions of functions that return GC'd data, or used to throw exceptions?

They will be accessible by importing std.xyz.

> Is the whole of std.v1 going to be deprecated at some point?

Probably. It's the natural course of things. But we won't be pressed by time.

> I think it'd be nice if there are a number of code examples worked out, showing what things are supposed to look like in a world with versioned standard library.

Great idea and comments, thanks.

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