D Language Foundation Monthly Meeting Summary for March 2022

[rikki cattermole]

> ## Razvan
> ### Reference counting
> Going through some old DRuntime pull requests, Razvan found several PRs 
> adding reference-counted things (RCArray, RCPointer, etc) from a period 
> when reference counting was a hot topic in the D community. The problem 
> with reference counting in D has been the transitivity of qualifiers 
> (e.g., you can't reference count an immutable object). Razvan remembered 
> he had drafted [a DIP for a `__metadata` storage 
> class](https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md). 
> In a forum discussion on that DIP, Timon Gehr had pointed out two 
> fundamental issues with it (anyone interested can see [the forum 
> discussion 
> thread](https://forum.dlang.org/post/3f1f9263-88d8-fbf7-a8c5-b3a2a5224ce0@erdani.org)). 
> Ultimately Razvan's progress stalled and he never submitted the DIP.

I stand by my comments about read only memory.

A person can still at runtime mark memory as read only, unfortunately I 
don't know how you can detect this in a compiler and fail compilation 
because of it.

My preference continues to be three new operator overloads methods for 
classes and structs.

opRefAdd, opRefSub, opReadOnly.

The first two are like destructors, they ignore const.
The last tells the type (must not be const) that it is going into read 
only memory allowing it to know that it is no longer writable. It would 
be required if reference counting methods are implemented.

The main difference to __mutable which was argued that it should not 
allow going into read only memory is that: the compiler can't detect if 
the user does it, but can prevent itself from doing it. That gives a 
very false sense of guarantee that it will not be.

Where as with this approach it is clearly the responsibility of the one 
who put it into read only memory to call the method and for the 
programmer who wrote the type to have done the right thing in the 
methods. Giving no guarantees and hence no sense of security.

> ### Attribute inference on private functions
> Mathias thinks that inference on private functions is something everyone 
> would want. It's something he heard Walter mention in the past. The 
> current blocker on that is that attribute inference doesn't work for 
> recursive functions. He thinks the solution is simple: you should assume 
> that the function has all the attributes; if you recurse on yourself, 
> the rest of the code will help you infer the attributes. Walter said 
> that makes sense; the more attribute inference we can do the better.

+1 infer everything!

I suspect you can do some quick and cheap tests in the parser to 
determine if given a function scope if a given attribute such as @safe 
should be inferred later on.

If done well, it could mean @safe by default!

> ## Andrei
> He started by arguing that reflection on built-in bitfields is "just 
> warped". You're going to have things less than 8-bit and to which you 
> cannot take a pointer. Any proposal for bitfields must account for that. 
> Walter's solution of having `__traits(getMembers)` return an aggregate 
> is only half of the story. What about the getters and setters? A library 
> solution has those, but for the built-ins, they're compiler magic. 
> Martin agreed (and this is his main sticking point; he brought it up in 
> the last meeting).

enum __c_bitfield;
is(typeof(value.bitfield) == __c_bitfield)

As long as .sizeof is the real size accounting for "empty" bits and 
alignment that should be a fairly safe way to go. It accounts for a 
single pointer and requires a special reflection mechanism to get the 
tuples of number of bits + names + types.