Worst ideas/features in programming languages?

[russhy]

On Tuesday, 12 October 2021 at 20:29:32 UTC, Paul Backus wrote:
> On Tuesday, 12 October 2021 at 19:41:57 UTC, H. S. Teoh wrote:
>> - C++ concepts-like feature of specifying the expected 
>> interface of a
>>   template parameter.
>>    - Yes, sig constraints fit the bill, kinda-sorta.  But it 
>> leads to
>>      poor, unhelpful error messages.  Yes, this can be fixed 
>> by using
>>      static if, pragma(msg), etc., but this requires a lot of 
>> extra work
>>      on the part of the user which should have been handled by 
>> the
>>      language.
>>    - Yes, there's a dub package that kinda-sorta does this. 
>> But again,
>>      this is something that should have been done by the 
>> language.
>
> You can get about 90% of the way to better constraint errors 
> with existing language features:
>
>     struct Check
>     {
>         bool passed;
>         string message;
>
>         T opCast(T : bool)() { return passed; }
>     }
>
>     enum hasFoo(T) =
>         Check(
>         	__traits(hasMember, T, "foo"),
>             "`" ~ T.stringof ~ "` must have a member named 
> `foo`"
>         );
>
>     struct Pass { int foo; }
>     struct Fail { int bar; }
>
>     // Can check with static assert
>     static assert(hasFoo!Pass);
>     static assert(!hasFoo!Fail);
>
>     // Works in constraints
>     auto getFoo(T)(T input)
>         if (hasFoo!T)
>     {
>         return input.foo;
>     }
>
>     static assert(__traits(compiles, Pass().getFoo));
>     static assert(!__traits(compiles, Fail().getFoo));
>
>     // Can check error message
>     pragma(msg, hasFoo!Fail.message);
>
> The only thing missing is a way to get the compiler to print 
> out your custom message, instead of (or in addition to) the 
> default "must satisfy `hasFoo!T`" message.
>
> I plan to write a DIP for this as soon as I am done with 
> @nodiscard.

templates doesn't work with DCD/DSymbol because it doesn't do 
semantic analysis, so that kind of features is impossible 
implement for tooling right now..


this is why things like tagged union (sumtype) and multiple 
return type should be implemented as language features, that way 
it is easier to parse (on top of other benefits)

please push for language feature! your work on sumtype was great, 
but there is much more to gain from upgrading it as a language 
feature