On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
wrote:
> I think Rust's lifetimes would be a huge change if ported to D. In Rust user types often need annotations as well as function parameters. People tend to want Rust's guarantees without the limitations. I think D does need some kind of scope attribute verification, but we need to throw out some of the guarantees Rust makes to get an appropriate fit for existing D code.
>

Rust is not the first language going that road. The problem is
that you get great complexity if you don't want to be too
limiting in what you can do. This complexity ultimately ends up
costing more than what you gain.

I think the sane road to go into is supporting
ownership/burrowing for common cases, and fallback on the GC, or
unsafe construct for the rest.

One have to admit there is no silver bullet, and shoehorning
everything in the same solution is not gonna work.

On 11/12/14 2:10 PM, deadalnix wrote:
> On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
> wrote:
>> I think Rust's lifetimes would be a huge change if ported to D. In
>> Rust user types often need annotations as well as function parameters.
>> People tend to want Rust's guarantees without the limitations. I think
>> D does need some kind of scope attribute verification, but we need to
>> throw out some of the guarantees Rust makes to get an appropriate fit
>> for existing D code.
>>
>
> Rust is not the first language going that road. The problem is
> that you get great complexity if you don't want to be too
> limiting in what you can do. This complexity ultimately ends up
> costing more than what you gain.
>
> I think the sane road to go into is supporting
> ownership/burrowing for common cases, and fallback on the GC, or
> unsafe construct for the rest.
>
> One have to admit there is no silver bullet, and shoehorning
> everything in the same solution is not gonna work.

I agree. This is one of those cases in which a good engineering solution may be a lot better than the "perfect" solution (and linear types are not even perfect...).

Andrei

Are you guys saying you don't feel this proposal is practical? http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a practical point of view. It solves the long-standings issues, like scope return values, in a very creative way.

On 13 November 2014 08:33, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 11/12/14 2:10 PM, deadalnix wrote:
>>
>> On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:
>>>
>>> I think Rust's lifetimes would be a huge change if ported to D. In Rust user types often need annotations as well as function parameters. People tend to want Rust's guarantees without the limitations. I think D does need some kind of scope attribute verification, but we need to throw out some of the guarantees Rust makes to get an appropriate fit for existing D code.
>>>
>>
>> Rust is not the first language going that road. The problem is that you get great complexity if you don't want to be too limiting in what you can do. This complexity ultimately ends up costing more than what you gain.
>>
>> I think the sane road to go into is supporting ownership/burrowing for common cases, and fallback on the GC, or unsafe construct for the rest.
>>
>> One have to admit there is no silver bullet, and shoehorning everything in the same solution is not gonna work.
>
>
> I agree. This is one of those cases in which a good engineering solution may be a lot better than the "perfect" solution (and linear types are not even perfect...).
>
> Andrei

Andrei Alexandrescu:

> I agree. This is one of those cases in which a good engineering solution may be a lot better than the "perfect" solution (and linear types are not even perfect...).

I am sure you are aware that the solution you are talking about is rather more complex (for both final programmers and language implementators) than the Rust solution.

Bye,
bearophile

On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:
> Are you guys saying you don't feel this proposal is practical?
> http://wiki.dlang.org/User:Schuetzm/scope
>
> I think it's a very interesting approach, and comes from a practical
> point of view. It solves the long-standings issues, like scope return
> values, in a very creative way.
>

You need to define ownership before defining borrowing.

On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:
> Are you guys saying you don't feel this proposal is practical?
> http://wiki.dlang.org/User:Schuetzm/scope
>
> I think it's a very interesting approach, and comes from a practical
> point of view. It solves the long-standings issues, like scope return
> values, in a very creative way.

It is better solved using static analysis and it is part of a bigger problem complex where ref counting should be considered. Otherwise you end up writing N versions of the same code. You want the same interface for GC, shared_ptr, unique_ptr, stack_allocated_data etc. Let the compiler do the checking.

What does "shared" tell the compiler? It tells it "retain no references after completion of this function". Like with "pure", it should be opposite. You should tell the compiler "I transfer ownership of this parameter". Then have a generic concept "owned" for parameters that is resolved using templates. Types that can be owned has to provide release() and move(). That would work for GC, shared_ptr, unique_ptr, but not for stack allocated data:

GC ptr: release() and move() are dummies.

shared_ptr: release() decrements, move() just transfers

unique_ptr: release() destroys, move() transfers

D has to stop adding crutches. Generalize!

On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:
>> Are you guys saying you don't feel this proposal is practical?
>> http://wiki.dlang.org/User:Schuetzm/scope
>>
>> I think it's a very interesting approach, and comes from a practical
>> point of view. It solves the long-standings issues, like scope return
>> values, in a very creative way.
>
> It is better solved using static analysis

You mean without additional hints by the programmer? That's not going to happen, realistically, for many reasons, separate compilation being one of them.

> and it is part of a bigger problem complex where ref counting should be considered. Otherwise you end up writing N versions of the same code. You want the same interface for GC, shared_ptr, unique_ptr, stack_allocated_data etc. Let the compiler do the checking.

Huh? That's exactly what _borrowing_ does. Ref-counting OTOH adds yet another reference type and thereby makes the situation worse.

>
> What does "shared" tell the compiler?

I guess you mean "scope"?

> It tells it "retain no references after completion of this function". Like with "pure", it should be opposite. You should tell the compiler "I transfer ownership of this parameter". Then have a generic concept "owned" for parameters that is resolved using templates.

That's what deadalnix's proposal does. Though I don't quite see what templates have to do with it.

> Types that can be owned has to provide release() and move(). That would work for GC, shared_ptr, unique_ptr, but not for stack allocated data:
>
> GC ptr: release() and move() are dummies.
>
> shared_ptr: release() decrements, move() just transfers
>
> unique_ptr: release() destroys, move() transfers
>

For a new language built from scratch, this might make sense. D is already existing, and needs to work with what it has.

> D has to stop adding crutches. Generalize!

That's what I'm trying to do with my proposal :-)

On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim Grøstad wrote:
> GC ptr: release() and move() are dummies.

Well, "move()" should obviously not be a dummy, but just a regular assignment that requires the object to be GC allocated…

What I am saying is that D needs type-classes for pointers so that you can write generic functions can be ignorant to specific allocation schemes and specify their minimum requirements. It basically means that in @safe code all raw pointers are "borrowed" and all owned pointers requires specification tha is either concrete (gc,shared,unique) or a templated generalization (single ownership, multiple ownership etc).

It seems a perfect for D to extend templates with more power and make good use of it now that C++ adds concepts.

On 13 November 2014 19:56, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:
>>
>> Are you guys saying you don't feel this proposal is practical? http://wiki.dlang.org/User:Schuetzm/scope
>>
>> I think it's a very interesting approach, and comes from a practical point of view. It solves the long-standings issues, like scope return values, in a very creative way.
>>
>
> You need to define ownership before defining borrowing.

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.

On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
> On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim Grøstad wrote:
>> It is better solved using static analysis
>
> You mean without additional hints by the programmer? That's not going to happen, realistically, for many reasons, separate compilation being one of them.

I think it can happen. D needs a new intermediate layer where you can do global flow analysis.

compile src -> ast -> partial evaluation -> high level IR -> disk

instantiate high level IR -> intermediate IR -> disk

global analysis over  intermediate IR

intermediate IR -> LLVM -> asm

> Huh? That's exactly what _borrowing_ does. Ref-counting OTOH adds yet another reference type and thereby makes the situation worse.

I don't like explicit ref counting, but it is sometimes useful and I think Rust-style ownership is pretty close to unique_ptr which is ref-counting with a max count of 1… You can also view GC as being implicitly ref counted too (it is "counted" during collection).

>> What does "shared" tell the compiler?
>
> I guess you mean "scope"?

:)

>> It tells it "retain no references after completion of this function". Like with "pure", it should be opposite. You should tell the compiler "I transfer ownership of this parameter". Then have a generic concept "owned" for parameters that is resolved using templates.
>
> That's what deadalnix's proposal does. Though I don't quite see what templates have to do with it.

My understanding of Deadalnix' proposal is that "owned" objects can only reference other "owned" objects. I think region allocators do better if you start constraining relations by ownership.

> For a new language built from scratch, this might make sense. D is already existing, and needs to work with what it has.

D need to appropriate what C++ has and do it better. Basically it means integrating GC pointers with unique_ptr and shared_ptr.

If D is going to be stuck on what it has and "fix" it with addig crutches it will go nowhere, and C++ will start to look like a better option…