On Monday, 8 December 2014 at 23:19:26 UTC, deadalnix wrote:
On Monday, 8 December 2014 at 20:54:54 UTC, Dicebot wrote:
But was there any reason why those traits (alien to type
qualifiers) were pursued? What is the problem with `ref`
simply meaning `non-null pointer` and allowing non-idempotent
ref(ref(int))?
Please no.
when you do int a; and then use a, you always either refer to a,
to memory storage (lvalue) or a, the value stored in that memory
(the rvalue).
When doing ref int a = xxx;
You specify that you don't create a new storage for a, but that
you must consider xxx as an lvalue, and bind the name a to that
same lvalue.
My thoughts have went totally different direction:
ref(int) a = &xxx; // ok
ref(int) a = xxx; // bad, can't initialize ref from value
ref(int) a = intptr; // ok, implicitly inject assert(intptr)
ref(int) a = null; // bad, can't initialize ref from literal
Now I see how issue may arise because of implicit conversion to
matching value type (when passing to as function argument for
example) but we do already have structs with `alias this` which
may need similar semantics - it needs to be defined anyway.
This is still offtopic. I support attempt to make scope a storage
class in general because this is an approach of minimal change
and still can be useful. Problem with defining it so that it
actually is useful.
