On 12/8/2014 3:14 PM, Dicebot wrote:
> On Monday, 8 December 2014 at 21:12:47 UTC, Walter Bright wrote:
>> On 12/8/2014 12:54 PM, Dicebot wrote:
>>> struct ByLine
>>> {
>>>     scope string front();
>>>     // ...
>>> }
>>>
>>> auto byLine(File file)
>>> {
>>>     return ByLine(file);
>>> }
>>>
>>> scope /* ref */ string foo(scope /* ref */ string input)
>>> {
>>>     return input[1..$];
>>> }
>>>
>>> void main()
>>> {
>>>     auto r = file.byLine.map!foo;
>>>     string s = r.front; // this should not compile
>>>     string s = r.front.dup; // this should compile
>>>
>>>     // how foo signature should look like for this to work?
>>> }
>>
>> front() should return a 'scope ref string'.
>
> That seems to contradict your other statement:
>
>> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.

Just make it a 'ref' parameter.


> Please check `foo()` once more - it needs to accept scope (ref) to be able to
> accept ByLine.front as an argument. And it also needs to pass it down the call
> chain - but returning `input` by reference is illegal according to
> abovementioned rule.

It can still be passed down as a 'ref' parameter.

On 12/8/2014 3:34 PM, bearophile wrote:
> If that topic is outside the scope of this discussion, then I have opened an ER
> on it:
> https://issues.dlang.org/show_bug.cgi?id=13838

1. You can always start a new thread here.
2. Thanks for filing the E.R.
3. When filing such, please check the [Hardware] settings. You have it set to [x86][Windows]. I reset them to [All][All].

On Tuesday, 9 December 2014 at 22:24:51 UTC, Walter Bright wrote:
>>> front() should return a 'scope ref string'.
>>
>> That seems to contradict your other statement:
>>
>>> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
>
> Just make it a 'ref' parameter.
>
>
>> Please check `foo()` once more - it needs to accept scope (ref) to be able to
>> accept ByLine.front as an argument. And it also needs to pass it down the call
>> chain - but returning `input` by reference is illegal according to
>> abovementioned rule.
>
> It can still be passed down as a 'ref' parameter.

But as far as I understand the spec it will result it this code failing too:

auto r = ["aaa", "bbb", "ccc"].map!foo;
// should compile but will fail because foo returns scope  ref:
string s = r.front;

What I mean is that in current proposal it is impossible to transfer scope information down the call chain - either function always returns scope ref or never. Which implies the necessity of something like `auto scope`...

On 12/8/2014 3:21 PM, deadalnix wrote:
> On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote:
>> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
>>
>
> It can safely be returned if you consider its lifetime as the
> intersection of the lifetime of the function's parameter.

The only purpose to a 'scope ref' parameter is to say it isn't being returned. 'ref' itself does not escape in any way other than by returning.

On Wednesday, 10 December 2014 at 05:23:29 UTC, Walter Bright wrote:
> On 12/8/2014 3:21 PM, deadalnix wrote:
>> On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote:
>>> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
>>>
>>
>> It can safely be returned if you consider its lifetime as the
>> intersection of the lifetime of the function's parameter.
>
> The only purpose to a 'scope ref' parameter is to say it isn't being returned. 'ref' itself does not escape in any way other than by returning.

That is a completely useless feature. Also, you want to have scope return for container like thing.

On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote:
> That why i say they are linked. I don't think your way of stating
> it contradict what I said.
>
> scope allow for manipulation of data without owning them.
> Whatever the owner is (be it the stack frame or anything else)
> doesn't really matter here.

It does when you return parts of it, like if you pass in a binary tree and return a node. Which you have to be able to do for the concept to make sense.

When you solve issues in language design you should address the hard issues first, because the easy issues will then tend to resolve themselves if the design is good. If you start with "the low hanging fruit" you end up with pointless special casing… D is already in that landscape and should try hard not to sink deeper into the muddy waters.

I posit that if you have a solution for ownership/retaining references then the solution for scope will come from this as a side-effect.

On Wednesday, 10 December 2014 at 15:15:59 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote:

> D is already in that landscape and should try hard not to sink deeper into the muddy waters.

Funny thing it is that it started exactly as a reaction to those muddy waters.

I believe this is the "Stroustrup curse":

"
Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I know of no exceptions, and there are good reasons for this phenomenon. [I wrote this before 2000; now (2012), the language part of the Java 7 specification is slightly longer in terms of number of pages than the ISO C++11 language specification.]
"

On Wednesday, 10 December 2014 at 16:17:16 UTC, eles wrote:
>
> I believe this is the "Stroustrup curse":
>
> "
> Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale.

I think he is making excuses for himself. Both Java and C++ are rather close to Simula+C as a starting point and have added cruft that should have been predicted in the initial version.

Anyway, I think language specs often are too verbose, they probably all hit around 700-1000 pages eventually due to editors cutting it back to that book-like size before it is published (and when the book-sized limit has been reached they feel they have done enough ungrateful and unpaid work so they don't cut more even though they could have).

On Wednesday, 10 December 2014 at 15:15:59 UTC, Ola Fosheim
Grøstad wrote:
> On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote:
>> That why i say they are linked. I don't think your way of stating
>> it contradict what I said.
>>
>> scope allow for manipulation of data without owning them.
>> Whatever the owner is (be it the stack frame or anything else)
>> doesn't really matter here.
>
> It does when you return parts of it, like if you pass in a binary tree and return a node. Which you have to be able to do for the concept to make sense.
>
> When you solve issues in language design you should address the hard issues first, because the easy issues will then tend to resolve themselves if the design is good. If you start with "the low hanging fruit" you end up with pointless special casing… D is already in that landscape and should try hard not to sink deeper into the muddy waters.
>
> I posit that if you have a solution for ownership/retaining references then the solution for scope will come from this as a side-effect.

That is completely off topic. this is a function parameter, you
can return scope, and you don't need to know who own the
container for that to work.

Granted, the current proposal lack the horsepower to do so.

On Wednesday, 10 December 2014 at 22:05:10 UTC, deadalnix wrote:
> That is completely off topic. this is a function parameter, you
> can return scope, and you don't need to know who own the
> container for that to work.

You have many scopes, if two different scopes pass in "horses" to a function in a recursive chain then you need to know which horse the returned "leg" belongs to…

But by all means… go ahead if you think it is off topic. (it isn't)