Shopping for template languages

[cc]

On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:
> But the compiler already yells at people for ambiguous function 
> usage anyway

So I considered it a bit, and here's a scenario I could find 
plausible:

```d
enum SqlResult { ok, error, constraint, } // inferred numeric 
basetype enum

bool ok;
string error;

SqlResult result;
result = constraint; // no problem
result = ok; // Ambiguous assignment to enum: use explicit 
SqlResult.ok, or
              // cast(SqlResult) ok to assign local variable
	result = SqlResult.ok; // explicit enum member
	result = cast(SqlResult) ok; // casts bool to SqlResult
result = error;  // actually, this should be ok, because you 
couldn't cast a string
                  // to a numeric enum anyway, but we could be 
picky about it anyway


SqlResult ok;
SqlResult result;
result = ok; // This is where things get silly. If you do this, 
you did something silly.
              // It could conceivably happen somewhere in a 
billion lines of code, but
              // if it does, the compiler should tell you you're 
silly. No one is going
              // to be sufficiently harmed by being informed that 
this is bad practice
              // and forced to throw in a cast() to make their 
intentions clear.
```
Globals should already be sorted out by existing syntax.  We have 
the "price to pay" of typing in an explicit `Enum.` or 
`cast(Enum)` but this only comes about if we happened to have a 
local variable by the same name as an enum member.  If you just 
don't do that, you aren't stripping yourself of any convenience.  
And if you do, well, what do you want?  The compiler can't read 
your mind ALL the time, but a lot of the time is better than none 
of the time, otherwise we wouldn't have auto, or template 
inference, or a whole bunch of other things.