Worst ideas/features in programming languages?

Paul Backus snarwin at gmail.com
Thu Jan 6 16:01:42 UTC 2022


On Thursday, 6 January 2022 at 07:14:49 UTC, bauss wrote:
> On Wednesday, 5 January 2022 at 22:42:14 UTC, Paul Backus wrote:
>>
>> This mechanism seems too powerful to me; for example, one 
>> could write code like the following:
>>
>>     struct S {
>>         string opArgs;
>>     }
>>
>>     string fun(S s) { return "S overload"; }
>>     string fun(string s) { return "string overload"; }
>>
>>     void main() {
>>         assert(fun(S()) == "S overload"); // fails
>>     }
>>
>> If there is to be any mechanism for automatic expansion of 
>> tuples, it should probably be narrow enough to avoid enabling 
>> surprises like this one.
>
> You could just make sure that the root type is always used if 
> an overload is available for it.
>
> Just like if you did:
>
> ```d
> struct S {
>   string opArgs;
>   alias opArgs this;
> }
> ```

Sure. You could make overload resolution consider a call that 
uses opArgs to be a "match with implicit conversion" [1], which 
would give it lower priority than an "exact match".

Which, IMO, perfectly illustrates the problem with opArgs: it's 
essentially a half-assed version of user-defined implicit 
conversions. Not powerful enough to do everything you'd want such 
a feature to do, but still powerful enough to shoot yourself in 
the foot.

[1] https://dlang.org/spec/function.html#function-overloading


More information about the Digitalmars-d mailing list