April 05, 2013
> 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
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
> 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
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
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
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
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
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
1 2 3 4 5 6
Next ›   Last »