On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
> For me "scopeness" is a property of "view", not object itself - this also makes ownership method of actual data irrelevant. Only difference between GC owned data and stack allocated one is that former can have scoped view optionally but for the latter compiler must force it as the only available.

Ha finally something start to make sense here.

On 12/15/2014 3:34 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> No wonder this is error prone. I suspect that with a cleaner implementation most
> of these problems will go away.

Sometimes, it isn't possible to see a cleaner way unless the dirty version is written first. Sometimes, there isn't a cleaner way :-(

But there are more issues with inout than are in mtype.c. The template implementation is full of it.

On 12/15/2014 1:28 AM, Dicebot wrote:
> On Monday, 15 December 2014 at 06:12:05 UTC, Walter Bright wrote:
>> C++ seems to do fine without it for const. It's a convenience feature.
>
> C++ const does not really restrict or affect anything "for real", it is
> non-existent feature.

C++ programmers constantly copy/pasta functions for the sole purpose of having one with const and one without.


> `scope` as proposed would result in inability to store
> result of predicates if those are ever to accept scope data - unless you defined
> two versions for each function that may possibly accept scope data with
> absolutely identical body.

If that is necessary, it is no worse than C++ is with const. It isn't a critical issue, or C++ would not be usable. I'd like to wait and see how this plays out.


>>>> 2. This is what scope inference is all about.
>>>
>>> Which only works with templates and lack of scope on arguments does not affect
>>> function body -> templates are not necessary, same as inout.
>>
>> It also works with all the lambdas, since source for them is always available.
>> I also wanted to make it (i.e. inference) work with auto functions, but Don
>> Clugston was the primary objector :-)
>
> This is not really answering my objections but side-stepping.

Inference addresses the issue.


> That would help with many issues but it need careful design to be well-accepted.
> How about teaming up to do a DIP about it at some point where this discussion is
> over? :P

Ok, sure.

On 12/15/2014 5:38 AM, deadalnix wrote:
> On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
>> For me "scopeness" is a property of "view", not object itself - this also
>> makes ownership method of actual data irrelevant. Only difference between GC
>> owned data and stack allocated one is that former can have scoped view
>> optionally but for the latter compiler must force it as the only available.
>
> Ha finally something start to make sense here.

Well, the DIP does defined scope in terms of a 'view' in just this manner.

I am obviously terrible at explaining things.

On Tuesday, 16 December 2014 at 01:00:47 UTC, Walter Bright wrote:
> On 12/15/2014 5:38 AM, deadalnix wrote:
>> On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
>>> For me "scopeness" is a property of "view", not object itself - this also
>>> makes ownership method of actual data irrelevant. Only difference between GC
>>> owned data and stack allocated one is that former can have scoped view
>>> optionally but for the latter compiler must force it as the only available.
>>
>> Ha finally something start to make sense here.
>
> Well, the DIP does defined scope in terms of a 'view' in just this manner.
>
> I am obviously terrible at explaining things.

No, I actually think the concept of view in the proposal is a good one. However, the proposal itself is too limiting.

On Tuesday, 16 December 2014 at 01:00:47 UTC, Walter Bright wrote:
> On 12/15/2014 5:38 AM, deadalnix wrote:
>> On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
>>> For me "scopeness" is a property of "view", not object itself - this also
>>> makes ownership method of actual data irrelevant. Only difference between GC
>>> owned data and stack allocated one is that former can have scoped view
>>> optionally but for the latter compiler must force it as the only available.
>>
>> Ha finally something start to make sense here.
>
> Well, the DIP does defined scope in terms of a 'view' in just this manner.
>
> I am obviously terrible at explaining things.

Don't you think there is a contradiction between this notion of "view" and being so focused on lifetimes? Does it make sense to explicitly throw away lifetime information and then spend a lot of effort on preventing lifetime-violating assignments to take place?

The current proposal is either too limiting or not limiting enough.

Too limiting, because programmers expect to gain something for making parameter types explicit. A naive "make no assumptions view" is more suitable as a default, then let the programmer specify the specifics where possible/needed, but you need to figure out the specifics first and let the "make no assumptions view default" be the leftovers…

The proposal is not limiting enough, because retaining knowledge about allocation order and aliasing brings important benefits:

An ordered "linear" parameter type would have properties such as:
- being aliasfree
- being on the stack, and cheaply checkable against the stack pointer

Sure, ref counting is fairly general for dynamic tracking, but it is also quite expensive. A check against the stack-pointer is much cheaper.

I think the uncanny valley metaphor that was brought up was quite good. If you are going to put in constraints on references, then do it in a manner that is easy to deal with and which brings benefits such as aliasfree references. If constraints become "arbitrary" then usability will suffer and it will seem pointless to put in extra work to use them.

You have already gone more or less wholesale for templates, so you might as well use it here as well, to bring substantial benefits to stack-allocation, because the current proposal is a very weak in terms of benefits.

On 12/16/2014 5:37 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> The current proposal is either too limiting or not limiting enough.

I'm afraid I don't understand at all what you wrote.

Walter Bright:

> I'm afraid I don't understand at all what you wrote.

Perhaps reading about linear type systems could help:

http://en.wikipedia.org/w/index.php?title=Substructural_type_system&redirect=no#Linear_type_systems

Bye,
bearophile

On Wednesday, 17 December 2014 at 07:48:52 UTC, bearophile wrote:
> Walter Bright:
>
>> I'm afraid I don't understand at all what you wrote.
>
> Perhaps reading about linear type systems could help:
>
> http://en.wikipedia.org/w/index.php?title=Substructural_type_system&redirect=no#Linear_type_systems

But note that we want a "relaxed" linear type system. In general, we are fine with multiple aliases, although there are some applications where strict uniqueness is useful. Deadalnix' proposal goes in this direction.

On Wednesday, 17 December 2014 at 11:13:02 UTC, Marc Schütz wrote:
> On Wednesday, 17 December 2014 at 07:48:52 UTC, bearophile wrote:
>> Walter Bright:
>>
>>> I'm afraid I don't understand at all what you wrote.
>>
>> Perhaps reading about linear type systems could help:
>>
>> http://en.wikipedia.org/w/index.php?title=Substructural_type_system&redirect=no#Linear_type_systems
>
> But note that we want a "relaxed" linear type system. In general, we are fine with multiple aliases, although there are

Pointer aliasing is an optimization killer, which is why C99 added the «restrict» keyword. I think in most cases the use of stack allocated objects tend to be alias-free, so it is important that this knowledge is retained so that the compiler can make use of it.

http://en.wikipedia.org/wiki/Pointer_aliasing