On 12/11/2014 17:16, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:
>> For example, taking a mutable borrowed pointer for a variable means
>> you can't even *read* the original variable whilst the pointer lives.
>> I think no one would try to make D do that, but Rust's reason for
>> adding it is actually memory safety (I don't quite understand it, but
>> it involves iterator invalidation apparently). It's possible their
>> feature can be refined, but basically 'mut' in Rust really means
>> 'unique'.
>
> In my proposal, there's "const borrowing". It still allows access to the
> owner, but not mutation. This is necessary for safe implementation of
> move semantics, and to guard against iterator invalidation. It also has
> other uses, like the problems with "transient range", e.g.
> stdin.byLine(), which overwrite their buffer in popFront(). On the other
> hand, it's opt-in; by default, owners are mutable while borrowed
> references exist.

Looks good. Personally I've been meaning to study your (whole) proposal, I think its a valuable analysis of what problems we could/should solve.

Just from a quick look, I wonder if 'const borrowing' could solve the scoped!C premature destruction problem:

C c = std.typecons.scoped!C();
// memory for c has already been freed (need auto c = ...)

If the destruction of Scoped is disallowed whilst an (implicit alias this) borrow for c is alive, the compiler can generate an error.

On Thursday, 13 November 2014 at 16:56:01 UTC, Nick Treleaven wrote:
> On 12/11/2014 17:16, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:
>>> For example, taking a mutable borrowed pointer for a variable means
>>> you can't even *read* the original variable whilst the pointer lives.
>>> I think no one would try to make D do that, but Rust's reason for
>>> adding it is actually memory safety (I don't quite understand it, but
>>> it involves iterator invalidation apparently). It's possible their
>>> feature can be refined, but basically 'mut' in Rust really means
>>> 'unique'.
>>
>> In my proposal, there's "const borrowing". It still allows access to the
>> owner, but not mutation. This is necessary for safe implementation of
>> move semantics, and to guard against iterator invalidation. It also has
>> other uses, like the problems with "transient range", e.g.
>> stdin.byLine(), which overwrite their buffer in popFront(). On the other
>> hand, it's opt-in; by default, owners are mutable while borrowed
>> references exist.
>
> Looks good. Personally I've been meaning to study your (whole) proposal, I think its a valuable analysis of what problems we could/should solve.
>
> Just from a quick look, I wonder if 'const borrowing' could solve the scoped!C premature destruction problem:
>
> C c = std.typecons.scoped!C();
> // memory for c has already been freed (need auto c = ...)
>
> If the destruction of Scoped is disallowed whilst an (implicit alias this) borrow for c is alive, the compiler can generate an error.

Const borrowing is not even necessary for that. The problem with `std.typecons.scoped!C` is that it implicitly converts to `C`. Instead, it should only convert to `scope!this(C)`, then the assignment will be rejected correctly:

    // ERROR: type mismatch: C != scope(C)
    C c = std.typecons.scoped!C();
    // ERROR: `c` outlives it's owner (temporary)
    scope(C) c = std.typecons.scoped!C();
    // OK: typeof(c) is now scoped!C
    auto c = std.typecons.scoped!C();

On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via Digitalmars-d wrote:
> On 13 November 2014 22:01, via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:
> D has attribute inference, that's like, a thing now.

Yes, these days D arguments go like this:

A: "I am saying no because it would go against separate compilation units."

B: "I am saying yes because we have attribute inference."

A: "But when will it be implemented?"

B: "After we have resolved all issues in the bugtracker."

A: "But C++17 will be out by then!"

B: "Please don't compare D to C++, it is a unique language"

A: "And Rust will be out too!"

B: "Hey, that's a low blow. And unfair! Besides, linear types suck."

A: "But 'scope' is a linear type qualifier, kinda?"

B: "Ok, we will only do it as a library type then."

A: "How does that improve anything?"

B: "It changes a lot, it means Walter can focus on ironing out bugs and Andrei will implement it after he has fixed the GC".

A: "When will that happen?"

B: "After he is finished with adding ref counters to Phobos"

A: "I thought that was done?"

B: "Don't be unreasonable, Phobos is huge, it takes at least 6 months! Besides, it is obvious that we need to figure out how to do scope before completing ref counting anyway."

A: "I agree…Where were we?"

B: "I'm not sure. I'll try to find time to write a DIP."


> I don't see anything in C++11/14/17 that looks like they'll salvage
> the language from the sea of barely decipherable template mess and
> endless boilerplate. It seems they're getting deeper into that
> madness, not less.

Stuff like auto on return types etc makes it easier and less verbose when dealing with templated libraries.

Unfortunately, I guess I can't use it on my next project anyway, since I need to support iOS5.1 which probably means XCode… 4? Sigh…

That's one of the things that annoy me with C++, the long tail for being able to use the new features.

> I spent the last 2 days doing some string processing in C++...
> possibly the least fun I've ever had programming. Somehow I used to
> find it tolerable!

Ack… I try to stick to binary formats. Strings are only fun in languages like Python (and possibly Haskell).

On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via
Digitalmars-d wrote:
> I don't think this proposal has issues with that.
> The thing at the root of the call tree is the 'owner'. Nothing can
> escape a scope call-tree, so the owner or allocation policy doesn't
> matter, and that's the whole point.

That is way to define ownerhsip so that is not a rebutal of my
comment. This makes assumption about ownership, that we may or
may not want;

I think the proposal is sound overall (I haven't try to explore
all special cases scenarios, so it is a reserved yes for now) but
going forward with this before defining ownership is not a good
approach.

On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via
Digitalmars-d wrote:
> D has attribute inference, that's like, a thing now.
> Theoretically, the compiler may be able to determine that a reference
> does not escape, and infer the 'scope' attribute, in many cases. This
> would be consistent with other attributes.
>

Yes, that is the only sane road forward.

On 14 November 2014 09:28, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via Digitalmars-d wrote:
>>
>> I don't think this proposal has issues with that.
>> The thing at the root of the call tree is the 'owner'. Nothing can
>> escape a scope call-tree, so the owner or allocation policy doesn't
>> matter, and that's the whole point.
>
>
> That is way to define ownerhsip so that is not a rebutal of my comment. This makes assumption about ownership, that we may or may not want;
>
> I think the proposal is sound overall (I haven't try to explore all special cases scenarios, so it is a reserved yes for now) but going forward with this before defining ownership is not a good approach.

I'm super happy your on board with this. You're often a hard sell :)

What about the definition of 'ownership' do you find problematic? It's clear we're not going to get multiple pointer types (read: owner types) like in Rust... so then ownership strategy will probably remain fairly arbitrary.

The point of scope seems to be precisely to set the problem of ownership aside. That leaves ownership at the root of the call-tree to remain being managed however the user likes.

Once we have scope, then we can have meaningful implementations of things like a unique pointer, and finally approach efficient RC. Personally, it has proven to be the most inhibiting barrier to further development in most areas I care about left.

On Friday, 14 November 2014 at 03:20:42 UTC, Manu via Digitalmars-d wrote:
> I'm super happy your on board with this. You're often a hard sell :)
>
> What about the definition of 'ownership' do you find problematic?

I don't find it problematic. However, the concept of burrowing (what we do with scope in that proposal) makes assumptions about ownership. So I'd like to see ownership addressed.

Ultimately, we can decide that ownership is loosely defined, but that may have very important consequences on the possibility - or not - to introduce ownership. I think ownership is an important concept to have to get the gc world and the non gc worlds interact nicely (which should be a big interest of yours as well).

> It's clear we're not going to get multiple pointer types (read: owner
> types) like in Rust... so then ownership strategy will probably remain
> fairly arbitrary.
>

I think it make sense to have something for ownership. The error of rust wasn't going that road, but going in that road 100%, which come at a cost at interface level which is too important. A simpler ownership system, that fallback on the GC or unsafe feature when it fall short.

I'm confident at this point that we can get most of the benefit of an ownership system with something way simpler than rust's system if you accept to not cover 100% of the scenarios.

> Once we have scope, then we can have meaningful implementations of
> things like a unique pointer, and finally approach efficient RC.
> Personally, it has proven to be the most inhibiting barrier to further
> development in most areas I care about left.

Yes, that is absolutely necessary to have safe RC, and a great tool to make it more efficient.

I'm not fan of unique as this is, IMO, a dumbed down version of what ownership can be, with no real upside.

On 2014-11-13 23:00, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> Unfortunately, I guess I can't use it on my next project anyway, since I
> need to support iOS5.1 which probably means XCode… 4? Sigh…

Can't you use Xcode 6 and set the minimum deploy target to iOS 5.1? If that's not possible it should be possible to use Xcode 4 and replace the Clang compiler that Xcode uses with a later version.

-- 
/Jacob Carlborg

On Friday, 14 November 2014 at 08:10:22 UTC, Jacob Carlborg wrote:
> Can't you use Xcode 6 and set the minimum deploy target to iOS 5.1? If that's not possible it should be possible to use Xcode 4 and replace the Clang compiler that Xcode uses with a later version.

I don't know yet, but the 5.1 simulator will probably have to run on OS-X 10.6.8 from what I've found on the net. Maybe it is possible to do as you said with clang… Hm.

> I think it make sense to have something for ownership. The error of rust wasn't going that road, but going in that road 100%, which come at a cost at interface level which is too important. A simpler ownership system, that fallback on the GC or unsafe feature when it fall short.
>
> I'm confident at this point that we can get most of the benefit of an ownership system with something way simpler than rust's system if you accept to not cover 100% of the scenarios.

Do you happen to have any concrete reasons for that? An example
maybe? Maybe start with explaining how in detail Rust's system is
too complex? I'm sure the Rust people will be interested in how
you can simplify a (most likely sound) type system that took
years to come up with and refine.