'scope ref' would allow, that both, lvalues AND rvalues can be
bound to. DIP 35 don't say anything about that.
Just to be clear:
The primary reason at all DIP 36 was created, was in general to
find a possibility that accept rvalues AND lvalues. That was
the initial reason.
I understand th
On Monday, 22 April 2013 at 17:01:43 UTC, Diggory wrote:
I like this except for the proposed "addressOf" function from
DIP25 which is massively overkill. The safe-ness of & on a ref
should be determined by the compiler, so that initially it
could be unsafe but that could be relaxed when the com
I like this except for the proposed "addressOf" function from
DIP25 which is massively overkill. The safe-ness of & on a ref
should be determined by the compiler, so that initially it could
be unsafe but that could be relaxed when the compiler can
determine that the pointer does not escape. Syn
On Wednesday, 17 April 2013 at 13:49:23 UTC, Robert wrote:
Hi!
I just read DIP35, sounds good as far as I can tell. What I
missed, is
overloading rules, what function would be chosen if you have
overloads
that take per value/auto ref/ref/scope ref/in ref for lvalues,
rvalues, ...
Best regard
Hi!
I just read DIP35, sounds good as far as I can tell. What I missed, is
overloading rules, what function would be chosen if you have overloads
that take per value/auto ref/ref/scope ref/in ref for lvalues,
rvalues, ...
Best regards,
Robert
On Sunday, 7 April 2013 at 05:36:26 UTC, Zach the Mystic wrote:
http://wiki.dlang.org/DIP35
I've talked about this before, but it seems like the right time
to formalize it, especially to illustrate the slight conflict
it would impose on using 'scope ref' to allow rvalue temporary
references.
http://wiki.dlang.org/DIP35
I've talked about this before, but it seems like the right time
to formalize it, especially to illustrate the slight conflict it
would impose on using 'scope ref' to allow rvalue temporary
references. If 'ref' itself were made completely safe using
'scope' and/or '
