## 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/[email protected])).
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.
