We should remove all that rot from phobos pronto.

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

On Friday, 7 May 2021 at 03:48:47 UTC, Andrei Alexandrescu wrote:
> We should remove all that rot from phobos pronto.
>
> https://github.com/dlang/phobos/pull/8029

Just a commoner here, can you explain for stupid what makes enum string a no go and why it should begone?

On 5/7/21 2:03 AM, evilrat wrote:
> On Friday, 7 May 2021 at 03:48:47 UTC, Andrei Alexandrescu wrote:
>> We should remove all that rot from phobos pronto.
>>
>> https://github.com/dlang/phobos/pull/8029
> 
> Just a commoner here, can you explain for stupid what makes enum string a no go and why it should begone?

Heavy toll on the infra for a very niche use case with trivial workarounds on the user side.

On Friday, 7 May 2021 at 11:55:53 UTC, Andrei Alexandrescu wrote:
> Heavy toll on the infra for a very niche use case with trivial workarounds on the user side.

It seems like the toll comes from isSomeString to return false for these nums, no? What is the root cause of this not working?

It doesn't seems like this should be a special case anywhere and just work.

On Friday, 7 May 2021 at 12:06:43 UTC, deadalnix wrote:
> On Friday, 7 May 2021 at 11:55:53 UTC, Andrei Alexandrescu wrote:
>> Heavy toll on the infra for a very niche use case with trivial workarounds on the user side.
>
> It seems like the toll comes from isSomeString to return false for these nums, no? What is the root cause of this not working?
>
> It doesn't seems like this should be a special case anywhere and just work.

"Is a string type" and "is implicitly convertible to a string type" are not the same thing.

On 5/6/21 11:48 PM, Andrei Alexandrescu wrote:
> We should remove all that rot from phobos pronto.
> 
> https://github.com/dlang/phobos/pull/8029

What do you mean "not support"? The language has enums derived from strings. Did you mean remove it from the language? That would be a severe penalty.

Did you mean that Phobos routines just should error whenever you use enum types derived from strings? That's also a severe penalty.

If you mean we shouldn't support it (as an ambiguous case) in *conversion* utilities (i.e. to/from string), then this makes some sense. But it's also not straightforward. Sometimes you WANT to convert from the enum to the base type. Sometimes you want to convert to the enum name. Going backwards (string to enum), which one makes more sense? It depends on context. It also doesn't help that a string enum implicitly converts to a string. The language is going to circumvent any policies Phobos has on that front.

For an example, in the serializers I have written, I usually have a "treat this enum type as it's base type" UDA, because the data inside the serialized format is the base type, but I want it as an enum in d-land. But it depends on the situation.

I think it makes possible sense to require either wrappers that clarify intent, or always treat enums the same way (as an enum). I think Phobos *mostly* does the latter. Erroring for ambiguity might be more disruptive than it's worth.

-Steve

On 5/7/21 10:16 AM, Paul Backus wrote:
> On Friday, 7 May 2021 at 12:06:43 UTC, deadalnix wrote:
>> On Friday, 7 May 2021 at 11:55:53 UTC, Andrei Alexandrescu wrote:
>>> Heavy toll on the infra for a very niche use case with trivial workarounds on the user side.
>>
>> It seems like the toll comes from isSomeString to return false for these nums, no? What is the root cause of this not working?
>>
>> It doesn't seems like this should be a special case anywhere and just work.
> 
> "Is a string type" and "is implicitly convertible to a string type" are not the same thing.

Yah. It's really been a string (heh!) of suboptimal decisions.

1. We wanted strings to be synonym to built-in slices of char. "Users should not need to define their own string type!" This has been D's billion dollars mistake.

2. Representing strings are char[] meant GC is a must and also there's long-distance coupling between callers and callees whenever strings are passed about: a callee may modify characters in the caller's string. Such changes could have been absolutely trivially disallowed with a user-defined string type, but see (1) and did I mention D's billion dollars mistake?

3. So yours truly (shudder) came up with the idea of doing strings as immutable(char)[] so that people can pass strings around, no coupling, no problem. GC is still a must. That satisfies (1) but bought us into the entire qualifiers business, which, any way I look at it, did not produce enough dividends compared to the effort put into it and the massive complications added to the language. (Aside: inout is the weirdest thing. How could we ever think that that was a good idea.)

4. When doing generic string functions for phobos, it made sense to support... oh wait a second we have so many string types. char[], wchar[], dchar[], each in triplicate because of const and immutable. So right of the bat we decided to support 9 string types. That was another mistake because nobody cares about wchar and dchar. Anyway, that's how isSomeChar and isSomeString were born.

5. Then came the question of ranges that have one of those 9 character types as elements... those should be supported too, no? IIRC at least a subset of phobos supports that stuff.

6. Then of course someone figured, wait a second, what about enums derived from strings and user-defined types that have an alias this as string... those deserve attention too, right? And right here we had descended into madness.


Compare all that with:

0. We put a String type in the standard library. It uses UTF8 inside and supports iteration by either bytes, UTF8, UTF16, or UTF32. It manages its own memory so no need for the GC. It disallows remote coupling across callers/callees. Case closed.

On 5/7/21 11:20 AM, Steven Schveighoffer wrote:
> On 5/6/21 11:48 PM, Andrei Alexandrescu wrote:
>> We should remove all that rot from phobos pronto.
>>
>> https://github.com/dlang/phobos/pull/8029
> 
> What do you mean "not support"? The language has enums derived from strings. Did you mean remove it from the language? That would be a severe penalty.

Enums derived from strings should not be supported as strings in the standard library.

> Did you mean that Phobos routines just should error whenever you use enum types derived from strings? That's also a severe penalty.

No it isn't.

On 5/7/21 11:20 AM, Steven Schveighoffer wrote:
> If you mean we shouldn't support it (as an ambiguous case) in *conversion* utilities (i.e. to/from string), then this makes some sense. But it's also not straightforward. Sometimes you WANT to convert from the enum to the base type. Sometimes you want to convert to the enum name. Going backwards (string to enum), which one makes more sense? It depends on context. It also doesn't help that a string enum implicitly converts to a string. The language is going to circumvent any policies Phobos has on that front.

Enums are poorly designed, but that's only a small part of the problem.

The bigger problem is the corruption of a noble principle. We wanted to be as generic as possible, and indeed in the beginning that seemed not only possible, but also easy. I don't think there's any other language or library supporting different character widths with this little aggravation.

Then this whole "be as generic as possible" became a slippery slope of inclusion. Allow enum strings. Allow alias this strings.

How about no.

User: "I have this enum string str and phobos won't consider it a string. Help!"

Another user: "Just use str.representation if you want to pass str around as a string."

User. "Cool."

Case closed.