No we should not support enum types derived from strings

[deadalnix]

On Thursday, 13 May 2021 at 01:03:19 UTC, Paul Backus wrote:
> On Wednesday, 12 May 2021 at 23:42:11 UTC, deadalnix wrote:
>> It is working in the simple case, it is expected to work from 
>> the caller's standpoint due to the LSP, but it doesn't work in 
>> practice due to some obscure implementation detail that is of 
>> little concern to the user.
>>
>> Pushing this on the user is not the way to go.
>>
>> If the library writer desire to bundle string/dstring/wstring 
>> in the same implementation, this doesn't change the fact that 
>> it ought to work with subtypes. Choosing to break this is what 
>> "flies in the face of the LSP".
>
> Well, no, it doesn't--because, again, the LSP doesn't apply 
> here in the first place, and never has. Flies in the face of 
> user expectations, perhaps--though even then, if the user looks 
> at the documentation and see `isSomeString!(typeof(fmt))`, is 
> it really reasonable for them to expect that a non-string type 
> will be accepted?
>
> I think it's a reasonable API design decision to support any 
> type that implicitly converts to a string type, but it's not 
> the *only* reasonable decision, and we ought to acknowledge the 
> costs as well as the benefits.
>
> Personally, my inclination is to err on the side of making the 
> standard library a little more complex so that user code can be 
> simpler, but Andrei makes a convincing argument that this 
> tendency has gotten us into trouble before [1]. How do we 
> decide where to draw the line? There has to be some principle 
> here beyond just "users expect it" and "respect the LSP."
>

While what you say is correct, I'm not convinced it is right.

We established before that effectively, we should expect the LSP 
to hold when values are passed down, but not when types are. 
Which i think we both agree is the reasonable thing to do here, 
because B being a subtype of A doesn't say anything about 
meta_typeof(B) being a subtype of meta_typeof(A), and therefore 
there is no expectation that the LSP holds.

So it is correct to assert that if format takes the type as a 
parameter, then there is no expectation that the LSP holds. It is 
also correct to say that the documentation describes things 
accurately.

But I strongly disagree with the fact that it is right.

To use an analogy, I could make a car where the gaz and break 
pedal are swapped, and explain as much in the user manual, yet, I 
fully expect people would crash such cars at a higher rate than 
the alternative.

In the case of format, we need to ask ourselves what does the 
user expect, to pass a value down or to pass a type (plus 
possibly a value) down? Because if it the first, then it 
reasonable from the user standpoint that the LSP works and if it 
is the second, then there isn't such an expectation.

The fact that we see people trying to do format!SomeEnumString , 
but not something like format!42 provides a good answer to that 
question. Format's parameter is expected to be a string, not any 
random type. And if that is the case, then it is reasonable to 
expect to LSP to hold.

Now, the matter of cost is an interesting one. But I argue that 
doing what the user expect ought to be cheap, if not the cheapest 
option available. This is simply the difference between a 
language that helps its users and a language that gets in the 
way. So if the cost is high, then we need to consider this high 
cost a serious problem to solve.