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