www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proof of concept for v2 - NO duplication, NO `static if` hell, NO

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://github.com/dlang/phobos/pull/8309

Destroy!
Oct 30 2021
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
Is there a new management philosophy? I.e. so there's a reason to 
think the stories of std.expiermental hell airnt going to repeat?
Oct 30 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 12:11 AM, monkyyy wrote:

 Is there a new management philosophy? I.e. so there's a reason to think 
 the stories of std.expiermental hell airnt going to repeat?


Thanks for asking this, forgot to mention that aspect.

The approach here is incremental release - at an extreme the PR could be 
merged right now and v2 become usable albeit with very few amenities - a 
few range functions and mismatch(). Whatever we didn't port to v2 yet 
will simply be absent, as opposed to working the wrong way.
Oct 31 2021
parent reply russhy <russhy gmail.com> writes:
Mistake

Multiple version of the same code can't coexist in the same 
codebase, it solve NOTHING other than inflating the STD with 
versions nobody will care

For V2 i personally envision a complete rewrite with clear goals 
in mind

Just adding a v2 for the sake of having v2 will only bring 
confusion without real long term goals/benefits, downsides 
outweighs the upsides


What's the long term goal? what problem v2 will solve?


Before any of that, i suggest finishing the allocator API story, 
then we can move forward in designing a v2 that focus on building 
a pragmatic and evolving STD that actually solve real world issues


Then se can have a SET of modules that can help solve real world 
issues

std.mem (allocators and stuff)
std.collections (data structures)
std.net (http/sockets/websockets)
std.utils (everything that can be reused for other modules)

Let's focus on tangible scenarios


And what about portable code?

WASM's rocket is about to lift off, will we miss it because we 
focused on versioning 
``AnotherWayOfDoingThisWithTemplateMixinV2AndV3CompatibleBtw``
Oct 31 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 12:57 PM, russhy wrote:

 Mistake
 
 Multiple version of the same code can't coexist in the same codebase, it 
 solve NOTHING other than inflating the STD with versions nobody will care


We don't have the resources to do maintenance naively, so we need to 
look at out-of-the-box solutions that leverage the power of the D 
language. The assertions that multiple versions can't coexist in the 
same codebase comes straight from within the box.


 For V2 i personally envision a complete rewrite with clear goals in mind


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&t
=2021-10-31&type=c) 
berni44, n8sh, ibuclaw, MoonlightSentinel and other heavy-hitters. And 
of course Razvan, the maintainer.

A complete rewrite is probably among the more naive choices, and assumes 
v2 will be perfect so it will need no breaking revisions on its own. I 
think that doesn't scale at all. Also working on all goals at the same 
time (autodecoding AND gc AND safety AND nicer ranges AND unify 
druntime+phobos AND library strings AND various improvements AND 
everyone's little list AND...) all but guarantees a never-ending 
Sisyphean task.


 Just adding a v2 for the sake of having v2 will only bring confusion 
 without real long term goals/benefits, downsides outweighs the upsides
 
 
 What's the long term goal? what problem v2 will solve?


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


 Before any of that, i suggest finishing the allocator API story, then we 
 can move forward in designing a v2 that focus on building a pragmatic 
 and evolving STD that actually solve real world issues


This is vague. You are implying currently Phobos does not solve real 
world issues which is factually false.


 Then se can have a SET of modules that can help solve real world issues
 
 std.mem (allocators and stuff)
 std.collections (data structures)
 std.net (http/sockets/websockets)
 std.utils (everything that can be reused for other modules)
 
 Let's focus on tangible scenarios
 
 
 And what about portable code?
 
 WASM's rocket is about to lift off, will we miss it because we focused 
 on versioning 
 ``AnotherWayOfDoingThisWithTemplateMixinV2AndV3CompatibleBtw``


Instead of seeing one compete with the other, I see versioning as 
opening opportunities and taking us out of the current stalemate.
Oct 31 2021
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 1:32 PM, Andrei Alexandrescu wrote:

 And of course Razvan, the maintainer.


And obviously Atila, sorry for forgetting to mention.
Oct 31 2021
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.


That's shifting the focus in a non-constructive manner. Obviously 
a forum discussion is primarily about getting feedback from 
end-users. That should not be considered to be «a problem». You 
need to ground the vision in concerns that end-users have.

Assuming that end-users matters, I'd say that for end-users 
having a small and stable standard library that focus on 
interfacing and basic I/O is preferable to a larger standard lib 
that keeps changing.
Oct 31 2021
prev sibling next sibling parent reply Johan <j j.nl> writes:
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
Oct 31 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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.
Oct 31 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Oct 31 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Oct 31 2021
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
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.)
Oct 31 2021
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 8:59 PM, 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.)


Thanks for asking. Not always a dozen users, and often different dozens 
for each little change. It just doesn't scale.
Oct 31 2021
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
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
Nov 01 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
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.
Nov 01 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Nov 01 2021
parent reply Adam D Ruppe <destructionator gmail.com> writes:
I remain skeptical this scheme will work as well when we get into 
the rest of the changes.... but I'm happy to see any action. Been 
too long with nothing. Even if the scheme doesn't work that well, 
let's just do it.
Nov 01 2021
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-01 9:48, Adam D Ruppe wrote:

 I remain skeptical this scheme will work as well when we get into the 
 rest of the changes.... but I'm happy to see any action. Been too long 
 with nothing. Even if the scheme doesn't work that well, let's just do it.


It all hinges on documentation, which is the most needed piece. I think 
the string mixins in the implementation are tolerable.

Either we use adrdox or improve ddoc.
Nov 01 2021
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 01, 2021 at 09:52:31AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]

 Either we use adrdox or improve ddoc.


I vote for integrating adrdox into ddoc.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com
Nov 01 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 1 November 2021 at 13:48:08 UTC, Adam D Ruppe wrote:

 I remain skeptical this scheme will work as well when we get 
 into the rest of the changes...


How will IDEs that auto inject import statements work?
Prefer the latest version?
Nov 01 2021
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 1 November 2021 at 18:12:26 UTC, Ola Fosheim Grøstad 
wrote:

 How will IDEs that auto inject import statements work?
 Prefer the latest version?


I don't know anything about that, but I would assume that'd work 
well enough. You should always prefer the newest version in new 
code.
Nov 01 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
 Alexandrescu wrote:




`C++20` is very powerful, `d` can't be complacent. We should 
learn the advantages of `C++`. We should also  introduce powerful 
features such as `... `and `concept` and `coroutine` etc. What a 
convenient tool. Why not learn it?
Like `manu` made a proposal, why doesn't `Walter` accept it?
As a long history language, C++ is undergoing radical 
improvement, so should we. Just provide a transition period of 
about `5~6` years.
And `C++23` reflection library, is coming.
Oct 31 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 9:35 PM, zjh wrote:

 Alexandrescu wrote:




 
 `C++20` is very powerful, `d` can't be complacent. We should learn the 
 advantages of `C++`. We should also  introduce powerful features such as 
 `... `and `concept` and `coroutine` etc. What a convenient tool. Why not 
 learn it?


The best aspect of C++ is the people working on it.

I think the very best work of my entire career is on the D language, by far.

Many folks much better than me have done the best work of their entire 
career on the C++ language, by far.

There are very good folks working on C++ coroutines. We just don't have 
very good folks working on D coroutines. Our haggling about improving 
the process etc cannot override a simple reality: we don't have all that 
ammo.

I think what we have is better than C++ concepts. I wouldn't touch C++ 
concepts. They are adding a lot of aggravation for very little power. We 
have the opposite ratio.


 Like `manu` made a proposal, why doesn't `Walter` accept it?


Which one? Manu made a number of proposals, and most if not all have 
been integrated in the language in a form of another, and for the better.


 As a long history language, C++ is undergoing radical improvement, so 
 should we. Just provide a transition period of about `5~6` years.
 And `C++23` reflection library, is coming.


We should. It's all about good folks working on D. No amount of telling 
what we should be doing will make that unnecessary.
Oct 31 2021
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/31/21 9:55 PM, Andrei Alexandrescu wrote:

 I think what we have is better than C++ concepts. I wouldn't touch C++ 
 concepts. They are adding a lot of aggravation for very little power. We 
 have the opposite ratio.


Forgot to mention: this is proof that even great folks and groups of 
folks may completely miss the point.
Oct 31 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 01:55:22 UTC, Andrei Alexandrescu 
wrote:

 On 10/31/21 9:35 PM, zjh wrote:



Manu's `...` proposal is very convenient. It is orthogonal to the 
`array`. It provides a variety of writing methods. With `...`, 
many implementations are very concise. It is basically a must for 
`C++` users.
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.
What we need is a good `organization` and gradually achieve the 
`priority goals`. In the `d Forum` and the `D home page `, 
`Users` can see the changes in the `future and now`. We need to 
`attract` excellent people, we need to do a good job in the 
`details` and let `d users` know the strength of `d`.
We should become stronger in being good at (`metaprogramming`) 
and fill the gap in the obvious `weakness(GC)`. In this way, 
naturally, when others think of `metaprogramming`, they think of 
`d`. If they can use `metaprogramming`, they can naturally be 
regarded as excellent.
Oct 31 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 03:34:46 UTC, zjh wrote:

 On Monday, 1 November 2021 at 01:55:22 UTC, Andrei Alexandrescu


We don't need to be better than `C++` in every aspect. We just 
need to be better than `C++` in the `most important / commonly 
used` direction. In this way, users will follow you.
We can investigate the `C++` users what they think are the `most 
important / commonly used`, and then we list them on the `vision` 
and work hard on it. Then the `C++` users who are interested in 
this aspect will naturally come.
Oct 31 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 03:49:34 UTC, zjh wrote:

`Library authors` are more important than `pure users` because 
`libraries` bring users.
Therefore, we should `give priority to` the satisfaction of 
`Library authors users`.
Similarly, we should `give priority to` satisfying `C++` users, 
because most `C++` users write libraries.
Oct 31 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Nov 01 2021
parent reply zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 13:19:04 UTC, Andrei Alexandrescu 
wrote:

 On 2021-10-31 23:49, zjh wrote:

 We don't need to be better than




Good, I just want to repeat, I hope `d` can remain work hard on 
`metaprogramming`, so that other languages can't compete with `d` 
in `metaprogramming`. In this way, I can big blow `d` language in 
QQ group.
Maintain the advantage of Dlang's `metaprogramming`, and users of 
other languages will be attracted.
Nov 01 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 01, 2021 at 01:37:56PM +0000, zjh via Digitalmars-d wrote:

 On Monday, 1 November 2021 at 13:19:04 UTC, Andrei Alexandrescu wrote:

 On 2021-10-31 23:49, zjh wrote:

 We don't need to be better than




 
 Good, I just want to repeat, I hope `d` can remain work hard on
 `metaprogramming`, so that other languages can't compete with `d` in
 `metaprogramming`. In this way, I can big blow `d` language in QQ
 group.  Maintain the advantage of Dlang's `metaprogramming`, and users
 of other languages will be attracted.


Lost in translation: "big blow" -> "heavily promote". ;-)


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a
much more efficient method; it is much closer to reality. -- D. Knuth
Nov 01 2021
parent zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 14:07:35 UTC, H. S. Teoh wrote:

 On Mon, Nov 01, 2021 at 01:37:56PM +0000, zjh via Digitalmars-d


大吹特吹,百度的翻译.就这样,请理解.
Nov 01 2021
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 1 November 2021 at 03:34:46 UTC, zjh wrote:

 Manu's `...` proposal is very convenient.


That DIP hasn't been accepted or rejected because it is stalled 
waiting for Manu. I will most likely be marking it as "Abandoned" 
in the near future.
Oct 31 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at 03:59:43 UTC, Mike Parker wrote:

 On Monday, 1 November 2021 at 03:34:46 UTC, zjh wrote:



Hope `manu` will pick it up.
Oct 31 2021
parent zjh <fqbqrr 163.com> writes:
On Monday, 1 November 2021 at


04:05:29 UTC, zjh wrote:

Another way is to "copy and modify" doctrine. What theirs(`C++`) 
is ours. Yes, we can.
In terms of what we are not good at. Yes, we can.
Oct 31 2021
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Mon, Nov 1, 2021 at 2:00 PM Mike Parker via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 1 November 2021 at 03:34:46 UTC, zjh wrote:

 Manu's `...` proposal is very convenient.


 That DIP hasn't been accepted or rejected because it is stalled
 waiting for Manu. I will most likely be marking it as "Abandoned"
 in the near future.


I reached ~95% confidence it would be rejected; Walter passed a confident
pre-judgment and started doing his own thing.
I did not know how to change that, so it seemed pointless to keep beating
on it.
I don't remember what was outstanding with it now, but I remember thinking
it's fairly trivial; a couple of sentences in the DIP that people didn't
like or thought could be clearer. The implementation is large-ish (has to
deal with a lot of different nodes), but it is nicely self-contained and
works well with just one or 2 incomplete edge cases.
I still think it should be in the language, but I'm out of energy to battle
for stuff. It's up to Walter... if he wants me to work on it, I could, but
he didn't like it and went with his own thing.
Dec 30 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 30 December 2021 at 23:51:30 UTC, Manu wrote:

You should insist that `Walter` to try it, he will feel really 
fragrant.
Right now ,I can't write a program without `...`,So,I hope d can 
also owns `...`.
Besides, your work is almost finished, only the last edge case , 
plus persuasion `walter`. It would be a pity if you don't have it 
done.
`...` is a very powerful feature.It is very important in the 
competition between D and `C++`.
Dec 30 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 31 December 2021 at 01:48:58 UTC, zjh wrote:


 `...` is a very powerful feature.It is very important in the 
 competition between D and `C++`.


There is another reason, `...` is orthogonal to `iterate arrays` 
.As a good language, orthogonal things should exist.
Dec 30 2021
parent zjh <fqbqrr 163.com> writes:
On Friday, 31 December 2021 at 01:58:12 UTC, zjh wrote:


 `...` is a very powerful feature.




`C++` write like this:
```d
template<class T,class...O>
void g(T&a,O&...o){
     (f(o,a),...);
}
```
you don't need to iterate arrays such, `very convient`.
Dec 30 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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.
Nov 01 2021
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 1 November 2021 at 13:18:07 UTC, Andrei Alexandrescu 
wrote:

 [snip]

 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.


I know that it is kind of tangential to the PoC, but the point 
that was raised is that concepts/etc resolve the issue of the 
"proper documenting of API's". Your response is that concepts are 
bad because they create a new language and it is better to 
express them within the current language, as in D. This is all 
fine, but it doesn't resolve the issue of "proper documenting of 
APIs" issue. Both points can be valid at the same time (concepts 
might be bad for the reasons you mention but D may still have an 
underlying issue wrt proper documenting of APIs).

My hope was that DIP 1023 (Resolution of Template Alias Formal 
Parameters in Template Functions [1]) would help on this issue, 
but it has been postponed and I believe the original author has 
moved on. Regardless, the code below has the example of an 
template alias that is used like a C++ concept.

```d
template Foo(T)
     if (is(T == int))
{
     alias Foo = T;
}

void foo(T)(Foo!T x) { }

void main() {
     Foo!int x;
     foo(x); //doesn't compile
     foo!int(x); //compiles
}
```

The only problem is the resolution. I don't see why you would 
need concepts in D if this issue is resolved.

[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md
Nov 01 2021
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-01 11:00, jmh530 wrote:

 On Monday, 1 November 2021 at 13:18:07 UTC, Andrei Alexandrescu wrote:

 [snip]

 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.


 
 I know that it is kind of tangential to the PoC, but the point that was 
 raised is that concepts/etc resolve the issue of the "proper documenting 
 of API's". Your response is that concepts are bad because they create a 
 new language and it is better to express them within the current 
 language, as in D. This is all fine, but it doesn't resolve the issue of 
 "proper documenting of APIs" issue. Both points can be valid at the same 
 time (concepts might be bad for the reasons you mention but D may still 
 have an underlying issue wrt proper documenting of APIs).
 
 My hope was that DIP 1023 (Resolution of Template Alias Formal 
 Parameters in Template Functions [1]) would help on this issue, but it 
 has been postponed and I believe the original author has moved on. 
 Regardless, the code below has the example of an template alias that is 
 used like a C++ concept.
 
 ```d
 template Foo(T)
      if (is(T == int))
 {
      alias Foo = T;
 }
 
 void foo(T)(Foo!T x) { }
 
 void main() {
      Foo!int x;
      foo(x); //doesn't compile
      foo!int(x); //compiles
 }
 ```
 
 The only problem is the resolution. I don't see why you would need 
 concepts in D if this issue is resolved.
 
 [1] https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md


That code looks pretty damn cool.
Nov 01 2021
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2021 2:55 PM, Andrei Alexandrescu wrote:

 I think what we have is better than C++ concepts. I wouldn't touch C++ 
 concepts. They are adding a lot of aggravation for very little power. We 
 have the opposite ratio.


The one thing signatures/typeclasses/concepts/traits all provide which D 
does not have is proper documenting of API's.

I.e.

auto:InputRange map(IR)(IR:InputRange input)
Oct 31 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 1 November 2021 at 01:55:22 UTC, Andrei Alexandrescu 
wrote:

 The best aspect of C++ is the people working on it.


The worst aspect of those people is that they keep pretending 
that C++ can become a good for high level programming, yet they 
fail to provide what people need for low level and performance. 
Such as SIMD types. Sadly g++ language extensions have far more 
impact than the stdlib.

The best way to judge a stdlib is to see if frameworks and large 
applications build on top of it or build their own bottom layer.

D can do the same. What is used by vibe-d and MIR, where does 
vibe-d and MIR build their own foundation?
Oct 31 2021
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.


 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.


Yep. This is the ordinary evolution of a language, but D has not 
figured out how to evolve. Always a false dichotomy where it's 
either a neverending stream of breaking changes or it's 100% 
stability.
Oct 31 2021
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Oct 31 2021
parent bachmeier <no spam.net> writes:
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.
Nov 01 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.

C++ std lib has always been a joke. One cannot use a joke for an 
argument. What is missing here is understanding architecture and 
layers. The std lib should be the bottom layer, and small, so you 
can keep it stable, efficient and provide targeted compiler 
optimizations. Changing this layer is incredibly expensive once 
you get it right... C++ never got it right, so people cannot 
fully rely on it as the bottom layer.
Oct 31 2021
parent reply bachmeier <no spam.net> writes:
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.
Nov 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 1 November 2021 at 13:01:26 UTC, bachmeier wrote:

 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.


There should certainly be a process for adding to a standard 
library, but "standard" usually means that you remain backwards 
compatible at the interface level for a very long time.

The core problem is not having a layered approach where you keep 
the stable inner core minimal. Then you can have other layers on 
top of that are application level libraries.

So for instance, you could have a higher level "ranges library" 
that is official, but that can be wholesale replaced if need be, 
without affecting code that only depend on the core.

Or you can do like Ada and have different profiles for different 
usage/hardware scenarios.

(I am leaving Lisp aside, as many considered it an archaic 
minimalistic language by the 1980s. The culture that ensured Lisp 
a prolonged life is rather peculiar and unusual.)



 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.


If you only extend, but then you don't need explicit versioning. 
Versioning the language/compiler would be sufficient.
Nov 01 2021
parent reply bachmeier <no spam.net> writes:
On Monday, 1 November 2021 at 13:38:44 UTC, Ola Fosheim Grøstad 
wrote:


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


 If you only extend, but then you don't need explicit 
 versioning. Versioning the language/compiler would be 
 sufficient.


Maybe I'm not understanding, but if V1 includes, say, 
std.range.primitives, you would know you could always rely on 
everything in it to work exactly the same way for the next 50 
years. V2 would include the first stab at std.range.interfaces, 
V3 would include a different version of std.range.interfaces that 
takes advantage of the things we've learned, and the end user 
could decide which to use. It's true that you wouldn't need 
versioning of std.range.primitives, but it's still part of the 
standard library and you'd need some way to identify that it's 
guaranteed to not change, so calling it V1 would be convenient. 
It wouldn't hurt anything to have only one version of some 
functionality.
Nov 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 1 November 2021 at 19:05:56 UTC, bachmeier wrote:

 Maybe I'm not understanding, but if V1 includes, say, 
 std.range.primitives, you would know you could always rely on 
 everything in it to work exactly the same way for the next 50 
 years. V2 would include the first stab at std.range.interfaces, 
 V3 would include a different version of std.range.interfaces


So, there may be many issues here. One obvious one would be 
template bloat.

A worse one is if you use a database library with a runtime that 
is V2, then you use two packages, one that uses V1 of the 
database library and another that uses V2 of the database 
library. As a result you try to inject V1 objects into a V2 
database and that cannot work, but having two separate database 
instances may also don't work.

Then you also have the issue of compiler compatibility. Will V1 
work with all future versions of compilers? If I have written an 
application for a customer, and he 2 years later wants to have a 
tiny feature added, that is basically just bolting on a package 
that depends on V2, but that package also uses new language 
features. Will it compile? For how many years will V1 remain 
supported and tested?

In general when updating a product you usually want to upgrade to 
the latest version of the compiler and libraries, to get 
bug-fixes. The more expensive that upgrade becomes, the less 
appealing the development environment becomes.

A better strategy is to automatically rewrite old code to new 
code through a transform. Like, with Angular, I run an 
(imperfect) transform that upgrades to the latest version. So I 
only have to do minimal work. Then I can add new features to the 
product using the latest feature set. At the very least a 
transform could inject TODO-comments telling you what to look out 
for. Go also provides similar tools I think (I don't recall)?
Nov 01 2021
parent harakim <harakim gmail.com> writes:
On Monday, 1 November 2021 at 19:45:53 UTC, Ola Fosheim Grøstad 
wrote:

 A better strategy is to automatically rewrite old code to new 
 code through a transform. Like, with Angular, I run an 
 (imperfect) transform that upgrades to the latest version. So I 
 only have to do minimal work. Then I can add new features to 
 the product using the latest feature set. At the very least a 
 transform could inject TODO-comments telling you what to look 
 out for. Go also provides similar tools I think (I don't 
 recall)?


I like this suggestion so much.
Nov 01 2021
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 1 November 2021 at 00:05:30 UTC, Andrei Alexandrescu 
wrote:

 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.


The kind of code you see in presentations at CppCon does not 
reflect the kind you see in frameworks and applications. The kind 
of people that go to conferences aren't necessarily 
representative of the average user of said language.

D could do better than C++ if you instead of going with hype go 
with empirical evidence and science. That means looking at other 
peoples code and figure out what people do with the 
language/standard library, why they do it that way, and why they 
don't do it the «intended» way.

C++ is pretty much dead as an application language. You're better 
off using Swift + C++, TypeScript + C++ or Dart + C++. D can in 
theory do better than this, because C++ cannot change its 
foundation.

So yes, change is necessary, but C++ does not provide a good 
model. C++ does not evolve in a way that is based on usability or 
empirical evidence. C++ has critical mass, it would have been 
dead without it.

Freezing D2 and starting on D3 would be a much better approach 
and would allow you to pick up ideas from other languages than 
C++ (e.g. Rust, Pony etc).



 There is stuff added to C++11, improved in C++14, and 
 deprecated in C++17. And nobody bats an eye.


Most of the deprecations in C++ are just signature adjustments. 
Let us keep it real.

The reason people are happy with changes to C++ is that the 
foundation was poor, that hardware has changed and changes are 
non-breaking for most code bases.
Nov 01 2021
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 1 November 2021 at 08:08:32 UTC, Ola Fosheim Grøstad 
wrote:

 Freezing D2 and starting on D3 would be a much better approach 
 and would allow you to pick up ideas from other languages than 
 C++ (e.g. Rust, Pony etc).


I agree with this
Nov 01 2021
prev sibling parent russhy <russhy gmail.com> writes:
On Monday, 1 November 2021 at 08:08:32 UTC, Ola Fosheim Grøstad 
wrote:


 Freezing D2 and starting on D3 would be a much better approach 
 and would allow you to pick up ideas from other languages than 
 C++ (e.g. Rust, Pony etc).


I also agree with this!

You build a future with the past in mind, not with you or it will 
become a burden

Python 2 -> 3  saved the language, it gave it a new youth
Nov 01 2021
prev sibling parent reply Johan <j j.nl> writes:
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
Nov 01 2021
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-01 7:28, Johan wrote:

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


Thanks for clarifying.


 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.


In the proposed scheme the marginal cost of keeping v1 around is very 
low. I'd say it's worth keeping it around until it becomes obsolete.


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


That is correct. A fully release version worth announcing and advising 
users to switch to will offer all amenities v1 does, under hopefully a 
much better API. Once a new version is released, the only rationale to 
use it concurrently with the old one is during migration of user codebase.


 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.


This is what effectively happens in the implementation. But all names 
will be available under the new version. It would be onerous to ask 
users to use "std" for some artifacts and "std.v2" for others. Just use 
"std.v2" everywhere and you know you've migrated.


 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.


Can't wait!
Nov 01 2021
prev sibling next sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
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&t
=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"?
Oct 31 2021
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
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
Oct 31 2021
prev sibling parent H. S. Teoh <hsteoh quickfur.ath.cx> writes:
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
Oct 31 2021
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
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&t
=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.
Nov 01 2021
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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&t
=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.
Nov 01 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2021 10:32 AM, 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, ...


I like the idea of incremental change. v2 could simply be the "no autodecoding" 
release. v3 would be "no gc". Etc.
Nov 01 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


Don't destroy - embrace!!!
Oct 31 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 31 October 2021 at 08:37:58 UTC, Imperatorn wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
 wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 Don't destroy - embrace!!!


Embrace - Extend - Extinguish
Oct 31 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 31 October 2021 at 11:42:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 31 October 2021 at 08:37:58 UTC, Imperatorn wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 Don't destroy - embrace!!!


 Embrace - Extend - Extinguish


Lol, YES!!!
Oct 31 2021
prev sibling next sibling parent reply eshsrt64 <eshsrt64 gmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


This is encouraging to see, real movement on the issue as opposed 
to endless discussions on the forum. The core D team are all 
working to better D, so whatever is done in this space will be an 
improved D experience. Whatever mistakes are made on this journey 
can be improved in v3, v4 etc. (and inevitably result in the 
collective forum wisdom speaking out "you are all idiots, why 
would you do that?!? I have no solution either myself, but 
clearly you did it wrong?!?".


but to do so will require small imperfect steps. My 
non-contributor request is: Please do not let perfection get in 
the way of progress.

Thanks!
Stew
Oct 31 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 31 October 2021 at 22:45:32 UTC, eshsrt64 wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
 wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 This is encouraging to see, real movement on the issue as 
 opposed to endless discussions on the forum. The core D team 
 are all working to better D, so whatever is done in this space 
 will be an improved D experience. Whatever mistakes are made on 
 this journey can be improved in v3, v4 etc. (and inevitably 
 result in the collective forum wisdom speaking out "you are all 
 idiots, why would you do that?!? I have no solution either 
 myself, but clearly you did it wrong?!?".


 but to do so will require small imperfect steps. My 
 non-contributor request is: Please do not let perfection get in 
 the way of progress.

 Thanks!
 Stew


Agreed. We can't just do nothing. If we at least start and "run 
the simulation" we'll see if it works or not. If we don't do 
anything, we don't learn anything.
Oct 31 2021
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


This is going to be hell.

Packages will end up breaking left and right in the future.
Nov 01 2021
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
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.
Nov 01 2021
prev sibling next sibling parent reply Ogi <ogion.art gmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


Good stuff.

Notably absent are `std.range.interfaces`. What are we going to 
do about them?
Nov 01 2021
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 01, 2021 at 02:09:44PM +0000, Ogi via Digitalmars-d wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309
 
 Destroy!


 
 Good stuff.
 
 Notably absent are `std.range.interfaces`. What are we going to do
 about them?


I think Andrei has indicated in the past that we want to get rid of it.

But IMO, practically speaking, sometimes object wrappers for ranges are
necessary. For example, if you need to alternate between two
incompatible UFCS chains based on a runtime condition (so you can't use
std.range.choose), or you need to return one UFCS chain or another from
a function based on a runtime condition:

	// This will not compile because of divergent return types.
	auto runtimeChoice(R)(R srcRange, bool condition) {
		if (condition)
			return srcRange.filter!someCriterion;
		else
			return srcRange.map!(x => someMap(x))
					.filter!someCriterion;
	}

	// So we need to do this instead:
	auto runtimeChoice(R)(R srcRange, bool condition) {
		if (condition)
			return inputRangeObject(srcRange.filter!someCriterion);
		else
			return inputRangeObject(srcRange.map!(x => someMap(x))
						.filter!someCriterion);
	}

Phobos v2 better have a way to deal with this.  Either that, or keep the
current definition of forward ranges until v3, to avoid too massive a
change.


T

-- 
There are two ways to write error-free programs; only the third one works.
Nov 01 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/1/21 10:09 AM, Ogi wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 Good stuff.
 
 Notably absent are `std.range.interfaces`. What are we going to do about 
 them?


I don't think they need particular attention - either publish them as 
they are, change them, or give up on them altogether (I believe allowing 
ref-type ranges was a mistake).
Nov 01 2021
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 01, 2021 at 11:39:46AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 11/1/21 10:09 AM, Ogi wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309
 
 Destroy!


 
 Good stuff.
 
 Notably absent are `std.range.interfaces`. What are we going to do
 about them?


 
 I don't think they need particular attention - either publish them as
 they are, change them, or give up on them altogether (I believe
 allowing ref-type ranges was a mistake).


So what do we do with functions that need to return ranges of multiple
types (albeit with compatible element types)?  Like std.range.choose
except with a runtime condition.  Or functions that return ranges whose
concrete types are not known until runtime?

If classes are not the answer, then what's the alternative?


T

-- 
They say that "guns don't kill people, people kill people." Well I think the
gun helps. If you just stood there and yelled BANG, I don't think you'd kill
too many people. -- Eddie Izzard, Dressed to Kill
Nov 01 2021
parent Ben Jones <fake fake.fake> writes:
On Monday, 1 November 2021 at 16:40:42 UTC, H. S. Teoh wrote:

 If classes are not the answer, then what's the alternative?


 T


How about a sumtype based wrapper?
Nov 01 2021
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 1 November 2021 at 15:39:46 UTC, Andrei Alexandrescu 
wrote:

 On 11/1/21 10:09 AM, Ogi wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 Good stuff.
 
 Notably absent are `std.range.interfaces`. What are we going 
 to do about them?


 I don't think they need particular attention - either publish 
 them as they are, change them, or give up on them altogether (I 
 believe allowing ref-type ranges was a mistake).


Easiest thing would be to wrap the class reference in a struct 
that calls `save` in its copy constructor, but does not expose a 
`save` method to its users:

import std.range.interfaces;

struct ForwardRangeObject(E)
{
     private ForwardRange!E payload;

      property auto ref front() { return payload.front; }
     // etc.

     this(ref inout typeof(this) other) inout
     {
         payload = other.payload.save;
     }
}
Nov 01 2021
prev sibling next sibling parent reply user1234 <user1234 12.de> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


Two questions, probably related to `canon`. I assume that two 
things are possible but I dont see how:

1. How does the module identifier part `v1` binds a current 
module name ?
For example the fact that `import std.v1.file` is the same as 
`import std.file`.

2. How does `v2` without actual `v2` module binds `v1` ?
For example `import std.v2.file` is the same as `import 
std.v1.file`, despite of no physical `std.v2.file` file (to pull 
v1).
Nov 01 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/1/21 10:54 AM, user1234 wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 Two questions, probably related to `canon`. I assume that two things are 
 possible but I dont see how:
 
 1. How does the module identifier part `v1` binds a current module name ?
 For example the fact that `import std.v1.file` is the same as `import 
 std.file`.


I don't understand this question, can you please rephrase?


 2. How does `v2` without actual `v2` module binds `v1` ?
 For example `import std.v2.file` is the same as `import std.v1.file`, 
 despite of no physical `std.v2.file` file (to pull v1).


There will be a physical `std.v2.file`. It may only contain aliases 
and/or public imports.
Nov 01 2021
parent user1234 <user1234 12.de> writes:
On Monday, 1 November 2021 at 17:32:21 UTC, Andrei Alexandrescu 
wrote:

 On 11/1/21 10:54 AM, user1234 wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 Two questions, probably related to `canon`. I assume that two 
 things are possible but I dont see how:
 
 1. How does the module identifier part `v1` binds a current 
 module name ?
 For example the fact that `import std.v1.file` is the same as 
 `import std.file`.


 I don't understand this question, can you please rephrase?


Based on the answer to the second question I think that what was 
asked in the first is not possible.
Nov 01 2021
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


All I can think of is "Why can't we used a package manager for 
Phobos?".

-Alex
Nov 01 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-01 13:49, 12345swordy wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 All I can think of is "Why can't we used a package manager for Phobos?".


A package manager solves problems orthogonal to those solved by this 
proposal.
Nov 01 2021
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 1 November 2021 at 18:55:34 UTC, Andrei Alexandrescu 
wrote:

 On 2021-11-01 13:49, 12345swordy wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 All I can think of is "Why can't we used a package manager for 
 Phobos?".


 A package manager solves problems orthogonal to those solved by 
 this proposal.


How is the old Phobos libraries are going to be distribute then? 
As part of the compiler bundle?

-Alex
Nov 01 2021
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-01 15:12, 12345swordy wrote:

 On Monday, 1 November 2021 at 18:55:34 UTC, Andrei Alexandrescu wrote:

 On 2021-11-01 13:49, 12345swordy wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 All I can think of is "Why can't we used a package manager for Phobos?".


 A package manager solves problems orthogonal to those solved by this 
 proposal.


 
 How is the old Phobos libraries are going to be distribute then? As part 
 of the compiler bundle?
 
 -Alex



They come with the distribution, yes.

In fact the way the PR is structured, it includes both versions in the 
same library. That's not a large increase in size because there same 
artifacts are used wherever appropriate.
Nov 01 2021
prev sibling next sibling parent dd <dd dax.moe> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

D and Phobos 2.000 and 2.098 (as their version are tightly 
coupled) went though so many versions and deprecations it's 
getting confusing to keep track what works and what used to work. 
I sometimes have to search changelogs to keep code compatible 
between releases across operating systems. A compiled list of 
features with their version ranges would be pretty big.

I think it'd be safe to do D3 as well, because this also includes 
language changes throughout the decade (I think D2 was from 
2008!).

Do take this as a grain of salt, I transitioned from .NET to D in 
around 2016 so maybe I am a little used to having my library 


But curious what std.v2 will bring. Will keep an eye open!
Nov 01 2021
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/21 9:59 PM, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309
 
 Destroy!


Made a change to the PR - now the new package is called "std.v2alpha" so 
as to clarify the transition process:

1. Add std.v2alpha
2. Add to std.v2alpha while continuing with the normal pace of releases
3. When everyhing in v1 was ported to v2, rename v2alpha to v2 and release.

That way we can implement complex versions without blocking the release 
process for a long time.
Nov 01 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2021 7:51 PM, Andrei Alexandrescu wrote:

 On 10/30/21 9:59 PM, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 Made a change to the PR - now the new package is called "std.v2alpha" so as to 
 clarify the transition process:
 
 1. Add std.v2alpha
 2. Add to std.v2alpha while continuing with the normal pace of releases
 3. When everyhing in v1 was ported to v2, rename v2alpha to v2 and release.
 
 That way we can implement complex versions without blocking the release
process 
 for a long time.


Or just `std2a`. It should not be a sub-package of std.
Nov 01 2021
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 2 November 2021 at 05:12:23 UTC, Walter Bright wrote:

 Or just `std2a`. It should not be a sub-package of std.


I think `std2` is a good idea, but please no `std2a`. It just 
means a needless name change later on. Documenting in bold that 
`std2` is still experimental ought to be enough. If the user does 
not bother with the docs he/she's not seriously avoiding problems 
anyway.
Nov 02 2021
parent zjh <fqbqrr 163.com> writes:
On Tuesday, 2 November 2021 at 11:33:16 UTC, Dukc wrote:

 On Tuesday, 2 November 2021 at 05:12:23 UTC, Walter Bright


std2a,Indicates a transition.
finished,may be use `std2`.
Nov 02 2021
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/2/21 1:12 AM, Walter Bright wrote:

 On 11/1/2021 7:51 PM, Andrei Alexandrescu wrote:

 On 10/30/21 9:59 PM, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 Made a change to the PR - now the new package is called "std.v2alpha" 
 so as to clarify the transition process:

 1. Add std.v2alpha
 2. Add to std.v2alpha while continuing with the normal pace of releases
 3. When everyhing in v1 was ported to v2, rename v2alpha to v2 and 
 release.

 That way we can implement complex versions without blocking the 
 release process for a long time.


 
 Or just `std2a`. It should not be a sub-package of std.


Correctamundo. It's up to us. Off the top of my hed there'd be a few 
practical issues with managing separate roots - makefile, build and 
test, and such. Package-level protection won't work across versions, 
which is a bummer - possibly a showstopper. But we can definitely look 
into it.
Nov 02 2021
prev sibling next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


I said it before

https://forum.dlang.org/post/wmqipfssxluzohrhxryy forum.dlang.org

I say it again, this is NOT a technical problem this is a 
management and leadership problem.

Destroyed!
Nov 01 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 November 2021 at 06:53:10 UTC, Robert burner 
Schadek wrote:

 I say it again, this is NOT a technical problem this is a 
 management and leadership problem.


Thus it is political.

Interestingly, C++ does have a solution called "inline namespace" 
that is meant to be used for mixing versions in libraries. So, 
without a prefix you get the current version (inlined namespace), 
but you can also ask for a specific version (explicit namespace).

Not quite the same as what is being proposed, but somewhat 
relevant still.

However, in my experience, this sometimes creates edge-cases 
where you get different typing behaviour related to 
namespace-nesting. I would be surprised if this does not happen 
in D as well, one way or another.
Nov 02 2021
parent reply Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 10:35:35 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 2 November 2021 at 06:53:10 UTC, Robert burner 
 Schadek wrote:

 I say it again, this is NOT a technical problem this is a 
 management and leadership problem.


 Thus it is political.


Properly because this is text not face to face, I don't get what 
I would take from this!?

Because political therefore bad?

Should that be your argument, I disagree.
Nov 02 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 November 2021 at 11:51:07 UTC, Robert burner 
Schadek wrote:

 Because political therefore bad?


Depends on the long term outcome. If you solve a current-day 
political issue by adding technical debt then you probably found 
the less optimal solution and stuck to it because it looks easy. 
If this creates a culture for less design and more evolution, 
then that is bad, as long term stability is important.

For instance: "with this solution we can always change it later, 
so we don't really have to be certain about what we do" is a 
political strategy that is easy to sell, but is very costly long 
term.
Nov 02 2021
next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 12:07:31 UTC, Ola Fosheim Grøstad 
wrote:

 For instance: "with this solution we can always change it 
 later, so we don't really have to be certain about what we do" 
 is a political strategy that is easy to sell, but is very 
 costly long term.


I think here lies the fundamental need for leadership.

I would argue that with the PR, linked in this forum thread,
the set of D developers will be empty before we find out whether
this can be reverted without problem or not.

I also can not proof that my solution means less problems in the 
long run.
I can only make an argument for it.

This is where the "making a decision" by leadership comes in.

Now for the baiting, in the end I can only hope that leadership 
makes the
bold choice that actually gets us good ;-)
Because, I really don't want to have write C++ or rust for a 
living.
Nov 02 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 November 2021 at 12:15:30 UTC, Robert burner 
Schadek wrote:

 I would argue that with the PR, linked in this forum thread,
 the set of D developers will be empty before we find out whether
 this can be reverted without problem or not.


I am not sure if the existing developers or older devs will be 
hit by it, because they are used to working around things and 
have a good model of the language and how it has evolved over 
time. They already have patience… (especially those that learned 
programming in the 80s and 90s, as they are used to weird things 
in the programming environment…)

But making it harder for newbies, is not a good. There is much 
less reason to be patient when other options offers you a 
smoother ride.

My experience from teaching a bit programming to students tells 
me that there is a big difference between those that learn 
programming today, and those that learned it 30 years ago. Making 
a dev environment tailored to the latter group is not sustainable…
Nov 02 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 2 November 2021 at 12:07:31 UTC, Ola Fosheim Grøstad 
wrote:

 For instance: "with this solution we can always change it 
 later, so we don't really have to be certain about what we do" 
 is a political strategy that is easy to sell, but is very 
 costly long term.


Huh? For me, it just comes out as trying to avoid the pitfalls of 
the waterfall model.

If a project wants to avoid needless politics and long-term 
costs, you probably are not saying it should go for waterfall in 
general.

So I think you're either saying that there is not much 
uncertainty about future in this particular case, or that the 
costs of getting it wrong are low even with an all-in approach? 
Or that D already has one leg in grave, so it's time for 
desperate moves?
Nov 02 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 November 2021 at 13:08:03 UTC, Dukc wrote:

 Huh? For me, it just comes out as trying to avoid the pitfalls 
 of the waterfall model.


So, for an iterative development model to function you need a 
solid foundation to build on. For an application the language + 
standard library + a good model of reality constitutes a minimal 
foundation. The standard library is the wrong place for 
experiments and revolutionary design…


 So I think you're either saying that there is not much 
 uncertainty about future in this particular case, or that the 
 costs of getting it wrong are low even with an all-in approach?


You should not put things in the core standard library that isn't 
proven already and  avoid experiments and "fashion". You can have 
officially backed application libraries and frameworks on top of 
it, distributed with the compiler.

You really don't want newbies to deal with 2 different string 
types, for instance, because one uses V1 and another uses V5. 
This is the difference between a toy language and a production 
language.


 Or that D already has one leg in grave, so it's time for 
 desperate moves?


No, it is natural for language designers to revise the language 
after a decade, like they are doing with Go. They are working on 
Go 2 now. And Go 1 had precursors.
Nov 02 2021
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 2 November 2021 at 06:53:10 UTC, Robert burner 
Schadek wrote:

 I said it before

 https://forum.dlang.org/post/wmqipfssxluzohrhxryy forum.dlang.org

 I say it again, this is NOT a technical problem this is a 
 management and leadership problem.

 Destroyed!


So I think your opinion is that we should simply break stuff hard 
and any proposed cure is worse than the interoperability problems 
that breaking stuff will cause? If that is the case, then yes it 
is a leadership problem from your viewpoint - they'd need to be 
convinced and dare to say it loud that we can't reasonably soften 
the breakage.

Otherwise, it is still technical. `static if`? `version`? Using 
multiple releases of Phobos in the same project? Andrei's 
solution? Definitely a most technical question.
Nov 02 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 2 November 2021 at 11:25:44 UTC, Dukc wrote:

 they'd need to be convinced and dare to say it loud that we 
 can't reasonably soften the breakage.


I think you need to look at who is hit harder and if they can 
take the hit. Hard breakage does not hit newbies, only 
experienced developers. Mixed versions is very likely to add more 
confusion for newbies and also for more complex programs (in the 
future).

This is essentially political horse-trading because:

1. You sacrifice keeping things simple for newbies in favour of 
making it more palatable to experienced developers.

2. You a pushing additional complexity issues into the future by 
making it seem smoother now.



 Otherwise, it is still technical. `static if`? `version`? Using 
 multiple releases of Phobos in the same project? Andrei's 
 solution? Definitely a most technical question.


A technical solution to a political challenge, but there will be 
debt to be paid later on (newbies and future complexity).
Nov 02 2021
prev sibling parent Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 11:25:44 UTC, Dukc wrote:

 So I think your opinion is that we should simply break stuff 
 hard and any proposed cure is worse than the interoperability 
 problems that breaking stuff will cause? If that is the case, 
 then yes it is a leadership problem from your viewpoint - 
 they'd need to be convinced and dare to say it loud that we 
 can't reasonably soften the breakage.

 Otherwise, it is still technical. `static if`? `version`? Using 
 multiple releases of Phobos in the same project? Andrei's 
 solution? Definitely a most technical question.


The first paragraph is closer.
I wouldn't say we "simple" break stuff.
I would even go so far that when you break dmd/phobos you have to 
make a really
good case for it and have PR's open to the 50 most used 
code.dlang packages and
all there dependencies.

I bet, most breaking changes, will result in hardly any 
problems/PR's.
Nov 02 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/2/21 2:53 AM, Robert burner Schadek wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 I said it before
 
 https://forum.dlang.org/post/wmqipfssxluzohrhxryy forum.dlang.org
 
 I say it again, this is NOT a technical problem this is a management and 
 leadership problem.
 
 Destroyed!


I agree with most of your points and definitely love the enthusiasm. But 
it seems to me you are looking at a one-off revolution and what we must 
define is a reproducible process. One does not exclude the other.
Nov 02 2021
next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu 
wrote:

 Destroyed!


 I agree with most of your points and definitely love the 
 enthusiasm. But it seems to me you are looking at a one-off 
 revolution and what we must define is a reproducible process. 
 One does not exclude the other.


Not it all, std2 sounds to me like std.experimental just with a 
different name.

For many of the changes you proposed of these posts, and years in 
general, I agree
with you or am not ashamed I don't know enough to make any 
contribution, and by
experience trust your decision.

I disagree on the reproducible process.
I think it is a trap.
IMO no breaking change is the same, therefore no reproducible 
process exists.

Removing std.string.soundex is different than killing 
auto-decoding.
I run in this trap, myself sooooo often.
"If I only had tool X, which takes me 1 month to build, task Y 
would be so simple and I have use it so often"
Or I can duck tape it right now, and the thing I want to be build 
is out of commission before the duck-tape fails.

Worse still, they are different but maybe in a completely 
different way.
For instance, how often is popFront called on a string.
Searching for soundex in D files on github is a lot easier, not 
perfect, but with a deprecation cycle, likely not a problem.

Again, I'm trying to say, that the D compiler as a library thing 
should be able to tell me how many cases of auto-decoding are 
there.

As we don't have that right now we could do something as shown 
here https://github.com/dlang/phobos/pull/8309/files#r741295406
and build all of code.dlang with the next dmd/phobos release and 
see how often that shows up.
Summit PR's to fix.
After the deprecation cycle we get D 102.0.0 or so and move on.
Nov 02 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-02 13:03, Robert burner Schadek wrote:

 On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu wrote:

 Destroyed!


 I agree with most of your points and definitely love the enthusiasm. 
 But it seems to me you are looking at a one-off revolution and what we 
 must define is a reproducible process. One does not exclude the other.


 
 Not it all, std2 sounds to me like std.experimental just with a 
 different name.


Must have been a miscommunication on my part. The two couldn't be more 
different.

std.experimental:

- NEW, as-of-yet unproven stuff
- Everything can change without notice
- Intent is to be moved to std when ready, where it ADDS functionality
- No changes that break std

std.v2:

- Fundamentally makes all existing functionality in std available
- Breaking API changes are possible, designed, and announced
- Additions are also possible, designed, and announced, but not 
quintessential (e.g. v2 with no autodecoding and improvements to safe, 
nogc, and nothrow would be a solid release)
- Intent is to coexist with std forever, with an eye toward deprecating 
the previous versions

I'd say any parallel between std.v2 and std.experimental is tragically 
misguided.
Nov 02 2021
next sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu 
wrote:

 Not it all, std2 sounds to me like std.experimental just with 
 a different name.


 Must have been a miscommunication on my part. The two couldn't 
 be more different.


I don't think the concern is that they are _intended_ to be 
similar, but that they will end up that way.


 std.experimental:
 - Intent is to be moved to std when ready, where it ADDS 
 functionality


And yet, std.experimental seems to be where code goes to die.  
std.sumtype exists, probably only because pbackus didn't let it 
go into std.experimental.

std.v2 is similar in at least one respect: it does not start off 
stable, and will presumably get that way at some point.  At what 
point do we say 'std.v2 is now stable'?  Well, that's exactly the 
same question we ask about things in std.experimental.


Here's one way it could be done: stabilize individual components 
of it at a time.  So, say: get rid of autodecoding and maybe the 
class range thing, and then say 'all std.v2 range interfaces are 
stable; others may not be'.  And at that point it is immediately 
useful.  Complete, stable std.v2 just happens when all of its 
components are stabilised.
Nov 02 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-02 18:27, Elronnd wrote:

 On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:

 Not it all, std2 sounds to me like std.experimental just with a 
 different name.


 Must have been a miscommunication on my part. The two couldn't be more 
 different.


 
 I don't think the concern is that they are _intended_ to be similar, but 
 that they will end up that way.
 

 std.experimental:
 - Intent is to be moved to std when ready, where it ADDS functionality


 
 And yet, std.experimental seems to be where code goes to die. 
 std.sumtype exists, probably only because pbackus didn't let it go into 
 std.experimental.


This seems to presuppose I was making the argument std.experimental is good.

FWIW I fully supported and encouraged Paul to merge his work straight 
into std.


 std.v2 is similar in at least one respect: it does not start off stable, 
 and will presumably get that way at some point.  At what point do we say 
 'std.v2 is now stable'?  Well, that's exactly the same question we ask 
 about things in std.experimental.


The answer to the same question is radically different for the two.

1. For experimental: has the artifact and its API mature? It's a vague 
question.

2. For stdv2: does it cover all symbols from std? It's a very precise 
question.


 Here's one way it could be done: stabilize individual components of it 
 at a time.  So, say: get rid of autodecoding and maybe the class range 
 thing, and then say 'all std.v2 range interfaces are stable; others may 
 not be'.  And at that point it is immediately useful.  Complete, stable 
 std.v2 just happens when all of its components are stabilised.


I don't think there's a need for such a staggered release. Use std2alpha 
or whatever until all components are ported, then rename and release 
officially.
Nov 03 2021
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 3 November 2021 at 15:02:57 UTC, Andrei 
Alexandrescu wrote:

 On 2021-11-02 18:27, Elronnd wrote:

 On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei 
 Alexandrescu wrote:

 [...]


 Must have been a miscommunication on my part. The two 
 couldn't be more different.


 
 I don't think the concern is that they are _intended_ to be 
 similar, but that they will end up that way.
 

 std.experimental:
 - Intent is to be moved to std when ready, where it ADDS 
 functionality


 
 And yet, std.experimental seems to be where code goes to die. 
 std.sumtype exists, probably only because pbackus didn't let 
 it go into std.experimental.


 This seems to presuppose I was making the argument 
 std.experimental is good.

 FWIW I fully supported and encouraged Paul to merge his work 
 straight into std.


Likewise.

I'm going to look at the PR in detail and comment later.
Nov 03 2021
prev sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu 
wrote:

 Must have been a miscommunication on my part. The two couldn't 
 be more different.


I think it was a miscommunication on my part.

I'm not concerned about adding stuff or change stuff.

Both std.experimental and std.v2 split phobos in two, that is my 
problem with
std.v2.



Please remove and add to phobos as much as you see fit, but don't 
split it.

I said it in the long post once before, but I say it again.
By the time I have explained to somebody new why D is in version 
2.099 with
phobos having parts in version v2 in addition to 
std.experimental, which is
was pretty much DOA, the person has installed, compiled, and run 
"hello world"
in rust.
Nov 03 2021
next sibling parent Greg Strong <mageofmaple protonmail.com> writes:
On Wednesday, 3 November 2021 at 16:51:43 UTC, Robert burner 
Schadek wrote:

 Both std.experimental and std.v2 split phobos in two, that is 
 my problem with
 std.v2.


No.  std.experimental does not split anything.  It's extra stuff 
you don't need to use.


 Please remove and add to phobos as much as you see fit, but 
 don't split it.


This statement must be hyperbole.  Obviously adding and removing 
from the standard library on a whim is not acceptable.
Nov 03 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-03 12:51, Robert burner Schadek wrote:

 On Tuesday, 2 November 2021 at 20:24:21 UTC, Andrei Alexandrescu wrote:

 Must have been a miscommunication on my part. The two couldn't be more 
 different.


 
 I think it was a miscommunication on my part.
 
 I'm not concerned about adding stuff or change stuff.
 
 Both std.experimental and std.v2 split phobos in two, that is my problem 
 with
 std.v2.


There's no splitting. You get to use std or std2. New code should use 
std2. Old code can migrate to std2. There's gotta be two by the 
pigeonhole principle. I don't see how this can be done otherwise.

The situation with std.experimental is very different. There a trivial 
claim can be made that there's "splitting" for the simple reason what's 
in one is not in the other.
Nov 03 2021
parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 3 November 2021 at 17:46:15 UTC, Andrei 
Alexandrescu wrote:

 There's no splitting. You get to use std or std2. New code 
 should use std2. Old code can migrate to std2. There's gotta be 
 two by the pigeonhole principle. I don't see how this can be 
 done otherwise.


It could be done by figuring out a way to use two Phobos versions 
side-by-side, for example 2.092 and 2.096. But your scheme has 
advantages over that so I'm still all in for `std2`.
Nov 03 2021
prev sibling next sibling parent Robert burner Schadek <rburners gmail.com> writes:
On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu 
wrote:

 and what we must define is a reproducible process.


I think this is the central conflict discussed by agile.
Nov 02 2021
prev sibling parent harakim <harakim gmail.com> writes:
On Tuesday, 2 November 2021 at 16:11:08 UTC, Andrei Alexandrescu 
wrote:

 On 11/2/21 2:53 AM, Robert burner Schadek wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 
 I said it before
 
 https://forum.dlang.org/post/wmqipfssxluzohrhxryy forum.dlang.org
 
 I say it again, this is NOT a technical problem this is a 
 management and leadership problem.
 
 Destroyed!


 I agree with most of your points and definitely love the 
 enthusiasm. But it seems to me you are looking at a one-off 
 revolution and what we must define is a reproducible process. 
 One does not exclude the other.


I'm curious if you could define the problem and, as a forum, we 
could look at other major languages to see how they solved it. 

Javscript/Typescript, Fortran, COBOL, Ada, and Ruby.

The solution seems to be to remove a language feature that is now 
obsolete, but only from the standard library. Is that correct? 
What problems is having this auto-decoding feature causing?
Nov 02 2021
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-10-30 21:59, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309
 
 Destroy!


Update: the entire std.algorithm.comparison is now versionable. Took 
about a day. I expect others to take less based on experience accumulated.

Found a bad compiler bug exposed by versioning equal(). Noted in the 
text. I don't think there's a workaround.

Spoiler: the code looks passable. Further spoiler: it's not quite a 
basket of fruit.
Nov 04 2021
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


I'm highly skeptical of making phobos 2 at this time. Maybe I'm 
wrong, but we discussed it not so long ago, and I tried to work 
on collections for it.

Problem is: it is not possible, as far as I can tell, to write a 
high quality collection library in D right now.

Because this is such a basic building block, I really question 
what phobos 2 can really achieve. The root cause of the mess that 
is phobos is that it is built on shaky grounds, and phobos 2 will 
be built on the same ground.
Nov 04 2021
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
 wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 I'm highly skeptical of making phobos 2 at this time. Maybe I'm 
 wrong, but we discussed it not so long ago, and I tried to work 
 on collections for it.

 Problem is: it is not possible, as far as I can tell, to write 
 a high quality collection library in D right now.

 Because this is such a basic building block, I really question 
 what phobos 2 can really achieve. The root cause of the mess 
 that is phobos is that it is built on shaky grounds, and phobos 
 2 will be built on the same ground.


Tbh. the best solution would be ditching Phobos for an entirely 
new standard library. Like writing it from scratch and when it's 
stable enough then provide a way of transitioning existing code 
to the new standard library.
Nov 04 2021
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:

 Tbh. the best solution would be ditching Phobos for an entirely 
 new standard library. Like writing it from scratch and when 
 it's stable enough then provide a way of transitioning existing 
 code to the new standard library.


Aren't you worried it would be much more difficult to finish with 
our manpower, and to get users to leave Phobos even then?
Nov 05 2021
parent bauss <jj_1337 live.dk> writes:
On Friday, 5 November 2021 at 09:45:49 UTC, Dukc wrote:

 On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:

 Tbh. the best solution would be ditching Phobos for an 
 entirely new standard library. Like writing it from scratch 
 and when it's stable enough then provide a way of 
 transitioning existing code to the new standard library.


 Aren't you worried it would be much more difficult to finish 
 with our manpower, and to get users to leave Phobos even then?


Sure. I'm not saying it's even possible, but just that it would 
be the best solution.
Nov 05 2021
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:

 Tbh. the best solution would be ditching Phobos for an entirely 
 new standard library. Like writing it from scratch and when 
 it's stable enough then provide a way of transitioning existing 
 code to the new standard library.


If it was kept smaller maybe. Meaning no xml, json, zip, zlib, 
digest, datetime, curl, odbc, checkedint, function, algorithms, 
sumtype, ranges, etc.

Move all those (same code) to a separate application layer with 
its own versioning.

But before doing anything like that you ought to:

1.  Go through Phobos and find all the language issues that are 
addressed in the Phobos code.

2. Change the language so that a new standard lib does not have 
to account for language weaknesses.

3. Write the standardlib in such a way that it is quite low level 
(everything should be meaningful in the context of embedded 
programming).

4. Identify interdependencies in the current Phobos library.

5. Write a set of "standard" application level libraries on top 
of that (streams/ranges, algorithms, compression, encryption 
etc), split up in such a way that there are no interdependencies 
(4).

It is totally doable. It is a management issue. Mostly political. 
Not so much to do with manpower or technicalities IMHO.
Nov 05 2021
next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 5 November 2021 at 10:53:17 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 5 November 2021 at 06:47:53 UTC, bauss wrote:

 Tbh. the best solution would be ditching Phobos for an 
 entirely new standard library. Like writing it from scratch 
 and when it's stable enough then provide a way of 
 transitioning existing code to the new standard library.


 If it was kept smaller maybe. Meaning no xml, json, zip, zlib, 
 digest, datetime, curl, odbc, checkedint, function, algorithms, 
 sumtype, ranges, etc.


```d
module phobosAlternative;
```

There. Licensed under boost :D.
Nov 05 2021
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 5 November 2021 at 10:53:17 UTC, Ola Fosheim Grøstad 
wrote:

 3. Write the standardlib in such a way that it is quite low 
 level (everything should be meaningful in the context of 
 embedded programming).



I think that's a wrong approach. It should provide both low-level 
and high-level approaches to problems.

Too much low-level is going to make it very verbose.
Nov 05 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 5 November 2021 at 12:48:01 UTC, bauss wrote:

 On Friday, 5 November 2021 at 10:53:17 UTC, Ola Fosheim Grøstad 
 wrote:

 3. Write the standardlib in such a way that it is quite low 
 level (everything should be meaningful in the context of 
 embedded programming).


 I think that's a wrong approach. It should provide both 
 low-level and high-level approaches to problems.

 Too much low-level is going to make it very verbose.


Not really, because if you write an application (like most do), 
you would use the shipped supported application library layer 
that is on top of the core standard library. By supported I mean 
that it is written by the same group that is responsible for the 
core standard library, and that is either provided in the same 
archive as the compiler or in a package manager that ships with 
the compiler.

However, if you write wrappers for some key C-libraries you would 
only depend on the core standard library and would not be 
affected by "application support" improvements. So that way you 
get a very stable wrapper.
Nov 05 2021
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-05 2:47, bauss wrote:

 On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 I'm highly skeptical of making phobos 2 at this time. Maybe I'm wrong, 
 but we discussed it not so long ago, and I tried to work on 
 collections for it.

 Problem is: it is not possible, as far as I can tell, to write a high 
 quality collection library in D right now.

 Because this is such a basic building block, I really question what 
 phobos 2 can really achieve. The root cause of the mess that is phobos 
 is that it is built on shaky grounds, and phobos 2 will be built on 
 the same ground.


 
 Tbh. the best solution would be ditching Phobos for an entirely new 
 standard library. Like writing it from scratch and when it's stable 
 enough then provide a way of transitioning existing code to the new 
 standard library.


The same issues will apply to that new standard library. We thought we 
knew all mistakes of D1 and Phobos1, too.
Nov 05 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu 
 wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 I'm highly skeptical of making phobos 2 at this time. Maybe I'm 
 wrong, but we discussed it not so long ago, and I tried to work 
 on collections for it.

 Problem is: it is not possible, as far as I can tell, to write 
 a high quality collection library in D right now.


That is an orthogonal problem. If we agreed to merge some 
collections library to Phobos, it could be done to Phobos 1 just 
as well. We don't need Phobos 2 for that.

Rather Phobos 2 lets us to discard some old design decisions we 
don't want to keep around anymore. Autodecoding is the best 
example, but not the only one. Were we simply to drop that in 
Phobos 1, it would be far more difficult to migrate for users.
Nov 05 2021
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 5 November 2021 at 09:43:21 UTC, Dukc wrote:

 On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei 
 Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 I'm highly skeptical of making phobos 2 at this time. Maybe 
 I'm wrong, but we discussed it not so long ago, and I tried to 
 work on collections for it.

 Problem is: it is not possible, as far as I can tell, to write 
 a high quality collection library in D right now.


 That is an orthogonal problem. If we agreed to merge some 
 collections library to Phobos, it could be done to Phobos 1 
 just as well. We don't need Phobos 2 for that.


No it is not.

The reason for which phobos v1 does not have a good set of 
collection have not changed, and therefore phobos v2 will not 
have a good set of collections.

Range have the exact same problem.
Nov 05 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-05 9:45, deadalnix wrote:

 On Friday, 5 November 2021 at 09:43:21 UTC, Dukc wrote:

 On Friday, 5 November 2021 at 03:12:39 UTC, deadalnix wrote:

 On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:

 https://github.com/dlang/phobos/pull/8309

 Destroy!


 I'm highly skeptical of making phobos 2 at this time. Maybe I'm 
 wrong, but we discussed it not so long ago, and I tried to work on 
 collections for it.

 Problem is: it is not possible, as far as I can tell, to write a high 
 quality collection library in D right now.


 That is an orthogonal problem. If we agreed to merge some collections 
 library to Phobos, it could be done to Phobos 1 just as well. We don't 
 need Phobos 2 for that.


 
 No it is not.
 
 The reason for which phobos v1 does not have a good set of collection 
 have not changed, and therefore phobos v2 will not have a good set of 
 collections.
 
 Range have the exact same problem.


Versioning and safe pure nogc reference counting (which is the true 
problem with implementing containers in D) are largely orthogonal. Or I 
should say just distinct, as "orthogonal" is unnecessarily precise.

We never got reference counting to work in safe pure nogc code. And we 
don't know how. If we did, we could write a slice-like type that does 
everything a slice does PLUS manages its own memory. This is the real 
problem with containers.
Nov 05 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu 
wrote:

 We never got reference counting to work in safe pure nogc code. 
 And we don't know how. If we did, we could write a slice-like 
 type that does everything a slice does PLUS manages its own 
 memory. This is the real problem with containers.


I'm pretty sure at least some of us (including Atila) know how.

In order to manually free memory in  safe code, you need a way to 
guarantee that the memory is not aliased. To do that, you either 
need runtime checks or compile-time checks. Runtime checks are 
possible in the current D language, but compile-time checks are 
not. So, if we want  safe  nogc containers without runtime 
overhead, a new language feature is required.

Unfortunately  live will not help with this, because it is 
possible (by design!) for  safe code to violate the invariants of 
 live.

One idea that's come up recently in the community Discord is a 
`unique(T)` qualifier, which would guarantee that any memory 
reachable via indirections in a given `T` value is not aliased. 
Exactly how to enforce this is an open question.
Nov 05 2021
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu 
 wrote:

 [snip]


 One idea that's come up recently in the community Discord is a 
 `unique(T)` qualifier, which would guarantee that any memory 
 reachable via indirections in a given `T` value is not aliased. 
 Exactly how to enforce this is an open question.


That's a new idea? I'm pretty sure there were a few people who 
have been saying something like that for a while. It's like 
putting  live into the type system.
Nov 05 2021
parent jfondren <julian.fondren gmail.com> writes:
On Friday, 5 November 2021 at 15:33:22 UTC, jmh530 wrote:

 On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:

 One idea that's come up recently in the community Discord is a 
 `unique(T)` qualifier, which would guarantee that any memory 
 reachable via indirections in a given `T` value is not 
 aliased. Exactly how to enforce this is an open question.


 That's a new idea? I'm pretty sure there were a few people who 
 have been saying something like that for a while. It's like 
 putting  live into the type system.


Vibe needed more than one grade of it: 
https://vibed.org/api/search?q=isolated
Nov 05 2021
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-05 11:06, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei Alexandrescu wrote:

 We never got reference counting to work in safe pure nogc code. And we 
 don't know how. If we did, we could write a slice-like type that does 
 everything a slice does PLUS manages its own memory. This is the real 
 problem with containers.


 
 I'm pretty sure at least some of us (including Atila) know how.


Please post the code, thanks!

Main problem is getting reference counting to work reliably in the 
presence of purity and immutability.
Nov 05 2021
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 5 November 2021 at 17:33:54 UTC, Andrei Alexandrescu 
wrote:

 On 2021-11-05 11:06, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei 
 Alexandrescu wrote:

 We never got reference counting to work in safe pure nogc 
 code. And we don't know how. If we did, we could write a 
 slice-like type that does everything a slice does PLUS 
 manages its own memory. This is the real problem with 
 containers.


 
 I'm pretty sure at least some of us (including Atila) know how.


 Please post the code, thanks!

 Main problem is getting reference counting to work reliably in 
 the presence of purity and immutability.


That and preventing the this pointer from escaping.
Nov 05 2021
parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 6 November 2021 at 01:45:45 UTC, deadalnix wrote:

 On Friday, 5 November 2021 at 17:33:54 UTC, Andrei Alexandrescu 
 wrote:

 On 2021-11-05 11:06, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei 
 Alexandrescu wrote:

 We never got reference counting to work in safe pure nogc 
 code. And we don't know how. If we did, we could write a 
 slice-like type that does everything a slice does PLUS 
 manages its own memory. This is the real problem with 
 containers.


 
 I'm pretty sure at least some of us (including Atila) know 
 how.


 Please post the code, thanks!

 Main problem is getting reference counting to work reliably in 
 the presence of purity and immutability.


 That and preventing the this pointer from escaping.


Unless I'm missing something, `scope` and dip1000 cover that.
Nov 08 2021
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 8 November 2021 at 14:01:18 UTC, Atila Neves wrote:

 On Saturday, 6 November 2021 at 01:45:45 UTC, deadalnix wrote:

 On Friday, 5 November 2021 at 17:33:54 UTC, Andrei 
 Alexandrescu wrote:

 On 2021-11-05 11:06, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei 
 Alexandrescu wrote:

 We never got reference counting to work in safe pure nogc 
 code. And we don't know how. If we did, we could write a 
 slice-like type that does everything a slice does PLUS 
 manages its own memory. This is the real problem with 
 containers.


 
 I'm pretty sure at least some of us (including Atila) know 
 how.


 Please post the code, thanks!

 Main problem is getting reference counting to work reliably 
 in the presence of purity and immutability.


 That and preventing the this pointer from escaping.


 Unless I'm missing something, `scope` and dip1000 cover that.


Which he covered in his message here:


 but instead we got a numerous features that don't quite work 
 ( nogc, DIP1000,  live, ...).
Nov 08 2021
parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 8 November 2021 at 14:04:40 UTC, bauss wrote:

 On Monday, 8 November 2021 at 14:01:18 UTC, Atila Neves wrote:

 On Saturday, 6 November 2021 at 01:45:45 UTC, deadalnix wrote:

 On Friday, 5 November 2021 at 17:33:54 UTC, Andrei 
 Alexandrescu wrote:

 On 2021-11-05 11:06, Paul Backus wrote:

 On Friday, 5 November 2021 at 14:08:58 UTC, Andrei 
 Alexandrescu wrote:

 We never got reference counting to work in safe pure nogc 
 code. And we don't know how. If we did, we could write a 
 slice-like type that does everything a slice does PLUS 
 manages its own memory. This is the real problem with 
 containers.


 
 I'm pretty sure at least some of us (including Atila) know 
 how.


 Please post the code, thanks!

 Main problem is getting reference counting to work reliably 
 in the presence of purity and immutability.


 That and preventing the this pointer from escaping.


 Unless I'm missing something, `scope` and dip1000 cover that.


 Which he covered in his message here:


 but instead we got a numerous features that don't quite work 
 ( nogc, DIP1000,  live, ...).




That would indicate to me that dip1000 doesn't work for that 
purpose, which it does, unless there's something I'm not aware of 
that isn't an implementation bug.  live isn't, err... live yet. I 
talked to Amaury about his opinions on  nogc so I get where he's 
coming from there, but it does do what it says on the tin.
Nov 08 2021
parent deadalnix <deadalnix gmail.com> writes:
On Monday, 8 November 2021 at 14:16:03 UTC, Atila Neves wrote:

 but instead we got a numerous features that don't quite work 
 ( nogc, DIP1000,  live, ...).




 That would indicate to me that dip1000 doesn't work for that 
 purpose, which it does, unless there's something I'm not aware 
 of that isn't an implementation bug.  live isn't, err... live 
 yet. I talked to Amaury about his opinions on  nogc so I get 
 where he's coming from there, but it does do what it says on 
 the tin.


DIP1000, for instance, is unable to cover more than one level of 
indirection.
Nov 08 2021
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:

 One idea that's come up recently in the community Discord is a 
 `unique(T)` qualifier, which would guarantee that any memory 
 reachable via indirections in a given `T` value is not aliased. 
 Exactly how to enforce this is an open question.


Yes. I would love to be able to express that an object has only 
one reference to it, as well as being able to express that 
requirement on arguments (which is like two sides of the same 
coin). The uniqueness doesn't always necessarily have to hold 
forever for it to be useful too.
Nov 05 2021
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 5 November 2021 at 15:06:58 UTC, Paul Backus wrote:

 One idea that's come up recently in the community Discord is a 
 `unique(T)` qualifier, which would guarantee that any memory 
 reachable via indirections in a given `T` value is not aliased. 
 Exactly how to enforce this is an open question.


Here you go: 
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2012-79.pdf

Unique is a bad name, because it doesn't have to be unique, it 
needs to be a unique entry point to a subgraph of objects, but 
there can be objects within the graph pointing back at the root.

If you go back to my old post about isolated and owned, you can 
find a lot of infos about this.

I'm a bit disappointed though, because I gather from your message 
that the idea is still new for most around here. It solves so 
many of D's problem that it's not even funny, but instead we got 
a numerous features that don't quite work ( nogc, DIP1000,  live, 
...).

I'm glad there is some renewed interest about this. This is such 
an obvious fit for D.
Nov 05 2021