Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1

[WebFreak001]

On Tuesday, 11 January 2022 at 02:22:06 UTC, Timon Gehr wrote:
> On 10.01.22 14:48, Mike Parker wrote:
>> 
>> 
>> This is the discussion thread for the first round of Community 
>> Review of DIP 1042, "ProtoObject":
>> 
>> https://github.com/dlang/DIPs/blob/2e6d428f42b879c0220ae6adb675164e3ce3803c/DIPs/DIP1042.md
>
> I like the fact that there will be a way out of the additional 
> Object bloat without using extern(C++). (My preferred way out 
> of this would still be to change Object.)
>
> However, I strongly dislike the new interfaces with their 
> opinions about which qualifiers have to be on which methods. 
> `const` prevents any kind of lazy initialization, and 
> realistically, what's the use case of those interfaces?

I partly agree with this, forcing attributes in the interface is 
most painfully for the programmer.

If every class and everything would perfectly use the attributes 
it would be no problem, but with `@safe` alone we can already see 
that not all code is written with perfect typing in mind. (half 
of dub packages not being @safe as default compatible and even 
more these attributes here not even being defaults as well)

[adr's recent patch](https://github.com/dlang/druntime/pull/3665) 
for @safe comparing classes shows that given more type 
information (not using the topmost class type) it's easy to do 
this with attributes. However this alone would fall short here if 
standard library stuff would suddenly use interfaces to accept 
arguments:

```d
void sort(Ordered[] objects);
```

Either this sort function can't be @nogc @safe nothrow pure, or 
all implementations everywhere in the D ecosystem need to force 
these attributes, even if they can't be properly used or need to 
use hacky workarounds. (I could imagine a custom class wanting to 
throw and/or allocate an exception or keep track of the number of 
comparisons) It's pick your poison here.

I think D is missing the required things to make this DIP viable 
now. e.g. for the example above it would be best if Ordered 
didn't force any attributes and instead the sort function could 
infer all the attributes from the Ordered type used. This is 
doable with templates right now but then the DIP goes in the 
wrong direction by forcing all the attributes and the question 
comes up as to why you would be using classes for this at all.

If the interfaces and everything in the DIP wouldn't force the 
attribute on the programmer, I would be more supportive of this 
DIP.