Phobos' slow descent into madness (page 2)

May 08, 2021

Re: Phobos' slow descent into madness

Posted by russhy
in reply to Berni44

Permalink

russhy

Posted in reply to Berni44

Permalink

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 pointed me to Dear Google Cloud: Your Deprecation Policy is Killing You. 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

On Friday, 7 May 2021 at 20:47:57 UTC, Andrei Alexandrescu wrote:

What the heck is that? Turns out it's a private symbol (that for some reason turns out to be duplicated in druntime and phobos). That private symbol, in turn, is used in a suite of desperate templates of which drabness is only overcome by their mind-numbing repetitiveness:

BooleanTypeOf
IntegralTypeOf
FloatingPointTypeOf
CharTypeOf
StaticArrayTypeOf
DynamicArrayTypeOf
AssocArrayTypeOf

What are these used for? Glad you asked! All these support "alias this" for the std.format.format function.

It's worth mentioning that, according to git blame, these symbols were all added by k-hara in 2012 and haven't changed in any fundamental way since. So I don't think the title of this thread quite represents the recent slow decline of things in phobos. Rather the decline happended abruptly 10 years ago. A more relevant question to ask ourselves is who approved these changes in 2012.

Forums