Phobos' slow descent into madness

[russhy]

On Saturday, 8 May 2021 at 10:01:27 UTC, Berni44 wrote:
> On Saturday, 8 May 2021 at 01:20:34 UTC, H. S. Teoh wrote:
>> I think his point is to collect the current criticisms of 
>> Phobos into a single point of reference, perhaps on the wiki 
>> or something, that could serve as a list of improvements to be 
>> made.
>
> +1 (would be nice to have forum feature to do that without 
> adding a new post)
>
> Recently there were rumors of Phobos 2.0. I think, that would 
> be a chance to get us out of the muds. But for that we need 
> such a signpost. It would help us to make us run all in more or 
> less the same direction.
>
> To a certain extend it will be possible to improve already on 
> Phobos 1.0. But we quite often reach points, where we need 
> deprecation cycles (or even 
> preview-switch-and-later-deprecation-cycles) which takes quite 
> a long time and is annoying for users too.
>
> n8sh 
> [recently](https://github.com/dlang/phobos/pull/7775#issuecomment-831996462) pointed me to [Dear Google Cloud: Your Deprecation Policy is Killing You](https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc). This made me thoughtful.
>
> I would probably like to have a policy like Java has (see the 
> article above for more details). But before starting such a 
> thing, I'd prefer to reach something really stable (compared to 
> stable with the meaning of changing things all two months, 
> which for me is somewhat a self-contradiction).
>
> So what I would like to do, would be:
>
> - Let Phobos 1.0 be as is (maybe even remove the deprecation 
> cycles).
> - Move over to Phobos 2.0 (e. g.) until summer 2023 (with a 
> list of goals at hand, e.g. no auto-*coughing*, a better 
> range/string concept, etc.). This will include several breaking 
> changes.
> - End of 2022 Phobos 2.0 will be frozen: Nothing new is 
> accepted, only bugfixes.
> - From summer 2023 on, Phobos 2.0 is stable. We guarantee 
> backward compatibility forever, but things may be deprecated.
> - We may then start working on Phobos 2.1, which will be 
> released in summer 2025 and frozen at end of 2024. And so on.

I agree with you 100%, it needs to happen, Python did that with 
Python 3 and got a new and prosperous life as a result

Same with .NET with dotnet core

Let's hope for APIs built with Allocators in mind
Let's hope people focus on efficiency and simplicity

I would love to contribute to such project, i already have a lot 
of code built with this in mind

I simply wish there was some sort of signature support for 
structs, that would make designing APIs much easier/nicer 
https://gist.github.com/rikkimax/826e1c4deb531e8dd993815bf914acea