View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2013
Re: My thoughts & tries with rvalue references
> How so? It does not break anything, as all "const scope" cases 
> can be processed with "const scope ref", in fact, compiler 
> should be allowed to degrade first to latter. Regarding meaning 
> - if "scope ref" means permissive rvalues (mutable ones), then 
> "const scope ref" means closer match for C++ "const &" - 
> constant references that can't escape scope.
What I meant was simply, that users which are using already "in 
ref" would get then the error: "redundant storage class: ref" 
because 'in' would contains 'ref' already. That's the whole 
reason of my rejection. ;)

> I actually have an impression you do really want exactly "const 
> scope ref" considering frequent references to C++.
No, I like to get 'scope ref' just as much as 'in ref' / 'scope 
const ref'. Mutable rvalue references are absolutely useful.
How did you get the idea?
April 05, 2013
Re: My thoughts & tries with rvalue references
On Friday, 5 April 2013 at 08:57:35 UTC, Namespace wrote:
>> How so? It does not break anything, as all "const scope" cases 
>> can be processed with "const scope ref", in fact, compiler 
>> should be allowed to degrade first to latter. Regarding 
>> meaning - if "scope ref" means permissive rvalues (mutable 
>> ones), then "const scope ref" means closer match for C++ 
>> "const &" - constant references that can't escape scope.
> What I meant was simply, that users which are using already "in 
> ref" would get then the error: "redundant storage class: ref" 
> because 'in' would contains 'ref' already. That's the whole 
> reason of my rejection. ;)

I am surprised to hear that redundant storage classes are 
considered an error by dmd :) Makes no sense for me, typical 
"generic code gen" use case story.

>> I actually have an impression you do really want exactly 
>> "const scope ref" considering frequent references to C++.
> No, I like to get 'scope ref' just as much as 'in ref' / 'scope 
> const ref'. Mutable rvalue references are absolutely useful.
> How did you get the idea?

Sorry then, I have misunderstood you then. I do want both "scope 
ref" and "const scope ref" too, but I was thinking that simple 
easy-to-use shortcut (in) should match most idiomatic and safe 
use case, and that should be "scope const ref". With an 
additional benefit of being able to replace values with refs 
transparently due to storage class/qualifier restrictions.

I don't have strong opinion here, it is just an idea that came to 
my mind today and felt tempting ;)
April 05, 2013
Re: My thoughts & tries with rvalue references
> I am surprised to hear that redundant storage classes are 
> considered an error by dmd :) Makes no sense for me, typical 
> "generic code gen" use case story.
http://dpaste.1azy.net/3ef7a084

> Sorry then, I have misunderstood you then. I do want both 
> "scope ref" and "const scope ref" too, but I was thinking that 
> simple easy-to-use shortcut (in) should match most idiomatic 
> and safe use case, and that should be "scope const ref". With 
> an additional benefit of being able to replace values with refs 
> transparently due to storage class/qualifier restrictions.
>
> I don't have strong opinion here, it is just an idea that came 
> to my mind today and felt tempting ;)

I like it also but was afraid that it could break user code. 'in 
ref' is allowed since 2.060 and many users use 'in' because it is 
shorter than 'const' and feels like the opposite of 'out'. :/
Otherwise that would be a good idea. Let's hear what Kenji says.
April 05, 2013
Re: My thoughts & tries with rvalue references
I also think that we should not change current `in` meaning.
It is already used as the shorthand of `const` widely, and it has value
semantics (make a copy of given argument). That's the major motivation to
add new syntax "scope ref" and "in ref".

Kenji Hara


2013/4/5 Namespace <rswhite4@googlemail.com>

> I am surprised to hear that redundant storage classes are considered an
>> error by dmd :) Makes no sense for me, typical "generic code gen" use case
>> story.
>>
> http://dpaste.1azy.net/**3ef7a084 <http://dpaste.1azy.net/3ef7a084>
>
>
>  Sorry then, I have misunderstood you then. I do want both "scope ref" and
>> "const scope ref" too, but I was thinking that simple easy-to-use shortcut
>> (in) should match most idiomatic and safe use case, and that should be
>> "scope const ref". With an additional benefit of being able to replace
>> values with refs transparently due to storage class/qualifier restrictions.
>>
>> I don't have strong opinion here, it is just an idea that came to my mind
>> today and felt tempting ;)
>>
>
> I like it also but was afraid that it could break user code. 'in ref' is
> allowed since 2.060 and many users use 'in' because it is shorter than
> 'const' and feels like the opposite of 'out'. :/
> Otherwise that would be a good idea. Let's hear what Kenji says.
>
April 06, 2013
Re: My thoughts & tries with rvalue references
On Friday, 5 April 2013 at 07:45:33 UTC, Dicebot wrote:
> On Friday, 5 April 2013 at 00:12:33 UTC, Zach the Mystic wrote:
>> struct Large { ... }
>> ref Large process1(@temp ref Large a) { return a; }
>> ref Large process2(@temp ref Large a) { return a; }
>>
>> Large* lar = &process2(process1(Large("Pass"," a ", "Large", 
>> "here")));
>
> This is exactly type of code I consider to be bad style and 
> want to see banned. Function that gets rvalue ref should never 
> return it as it knows nothing about its lifetime. Actually, I 
> can't even find scope definition for temporaries in dlang.org, 
> but it is hardly a good thing to rely on anyway. Best is to 
> assume that when function is gone, so is rvalue temporary.

It may be bad style. (I don't know if it's bad style.) But there 
is significant thought (such as in DIP25) going into the idea 
that the programmer doesn't even *need* to track the lifetime of 
a reference, that the compiler can do it automatically. I don't 
think it's documented, but there is already an error issued for 
local variables which are returned by reference, which is the 
same behavior as 'scope' described.

ref int func() {
  int y;
  return y; // Error: may not be escaped
}

There is no current checking, however, for returning the result 
of a function which returns ref.

ref int func(ref int a) { return a; }
ref int func2() {
  int x;
  return func(x); // Passes when it should error, x escaped
}

DIP25, to be on the safe side, proposes that since func() takes a 
ref, it must be assumed to return the ref it takes. So func(x) 
will be treated as a local since x is a local. The only flaw with 
DIP25 is that it's actually *too* safe, and it will shut down 
some cases which are perfectly fine:

ref int copy(ref int a) {
  int *b = new int;
  *b = a;
  return *b; // return by ref
}

I have tried to address this issue elsewhere (and I actually need 
to make formal proposals which I haven't done yet), but the main 
point is that even accepting a temporary rvalue is the kind of 
thing which can be tracked at the call site, and not the function 
itself.

ref int func(ref int a) { return a; }
ref int func2() {
  int x;
  return func(x); // Error, according to DIP25
  return func(25); // Error also, temp 25 is local, just like x

  static int* y;
  return func(y); // Okay because y is not local
}

So there are two different issues going on.

Now what's the big deal, you may ask. Any function designed to 
accept an rvalue temporary can't possibly want to return that 
parameter by reference. And you may be right. In fact, the only 
reason I know to allow it was mentioned above, because it would 
allow efficient chaining of operations on a single entity passed 
by reference instead of by value, with each function modifying it 
before passing it on. But it's the *caller* who needs to know how 
local the reference is, not the receiving function. And that 
leads me into the other issue, which is that I had thought 
'scope' would be a great way to tell a calling function "no, this 
ref will not be returned to you". (This is the issue I need to 
make a formal proposal on.) And that leads to a direct 
contradiction with the proposed use of 'scope ref', as I have 
written in my answer to Kenji Hara's defense of 'scope ref'.

ref int func(scope int a) {
  return *new int; // Okay
  return a; //Error: can't return a parameter marked scope
}

Now the checking used by DIP25 could call func() safely:

ref int testFunc() {
  int x;
  return func(x); // Okay, I know x will not be returned
}

So 'scope' and 'scope ref' would mean two different things, and 
there might be some cases where you only want one of the features 
and not both.

To address this issue, I thought of a slightly desperate way to 
actually resolve this problem without any new storage class, such 
as 'ref&' or '@temp ref'. In order to indicate 'scope' in 
addition to 'scope ref', you'd simply write 'scope scope ref'. 
Two scopes! The defense of this position is that the actual use 
of 'scope' by itself would rarely be used, and so the strange 
appearance of two scopes would almost never happen.

> Your code begs for using plain refs and storing Large in a 
> stack variable before calling function chain. May look a bit 
> less convenient but much more reliable and understandable.

Yes, this issue would be simplified by simply saying that any 
function which accepts rvalue temporaries must treat those 
parameters as locals and not allow returning them. It imposes a 
minor inconvenience on the programmer who must declare an lvalue 
to use any function which *does* return a reference to the 
parameter. I actually think this is a sound design choice, but at 
least it will be a choice and not a "lucky" accident.

One last thing about 'scope ref', which would be usable for the 
new feature, assuming the design choice just mentioned was 
accepted. It's not as obvious that it implicitly allows rvalue 
temporaries as something blunt like '@temp ref' would be, or as 
inconspicuous as 'ref&' would be. Also, it sort of suggests that 
ordinary 'scope' is not in fact passed by ref, which I is 
somewhat misleading. So it does save on syntax creep, but it also 
has those three disadvantages.

I think that's all I have to say about this topic!
April 06, 2013
Re: My thoughts & tries with rvalue references
On Saturday, 6 April 2013 at 07:50:10 UTC, Zach the Mystic wrote:
> ...
Ye, I know it and I hate DIP25. It tries to limit references to 
allow them in @safe and I hate @safe as much. Type system will 
lack plain "non-null pointer" type then. Sad I can do nothing 
about it.
April 06, 2013
Re: My thoughts & tries with rvalue references
I am currently in the process to collect the necessary 
information and would gladly give you the previous data. Then you 
could already take a look on it, if you still need something or 
if something is missing and if, what. Then I have a clearer idea. 
That would certainly be very nice of you.
For this purpose it would be good to have your email. Or should I 
post the DIP proposal here?
April 06, 2013
Re: My thoughts & tries with rvalue references
On Saturday, 6 April 2013 at 17:50:31 UTC, Namespace wrote:
> I am currently in the process to collect the necessary 
> information and would gladly give you the previous data. Then 
> you could already take a look on it, if you still need 
> something or if something is missing and if, what. Then I have 
> a clearer idea. That would certainly be very nice of you.
> For this purpose it would be good to have your email. Or should 
> I post the DIP proposal here?

m.strashun at gmail
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home