Proof of concept for v2 - NO duplication, NO `static if` hell, NO difficulty with interoperability

[Andrei Alexandrescu]

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.