On 13 November 2014 20:38, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
>
> 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…

I don't follow how you associate that opinion with implementation of
scope. I think it's practical and important, and the point is the
opposite of what you say from my perspective.
scope is the best approach I've heard to address these differences in
allocation patterns without asserting any particular policy on the
user. Escape analysis is the only solution I know to safely allow
pointers to be passed around without having to worry about how they
were allocated.
By contrast, I have no idea what you're suggesting, or how it's not a
'crutch'... but if it's anything to do with C++, I'm dubious, and
kinda frightened.


Incidentally, I've recently started a new C++ job, first C++ I've
written in some years... (after ~18 years, 12 professionally,
full-time C/C++)
After having adapted to D and distancing from C++, trying to go back
is like some form of inhuman torture!
I really don't remember it being as bad as it is... the time away has
given me new perspective on how terrible C++ is, and I can say with
confidence, there is NOTHING C++ could do to make itself a 'better
option' at this point.
Judged on common ground, there is no competition. It's only 'the devil
you know' case that I think can possibly make an argument for C++.

On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:
> On 13 November 2014 20:38, via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
>>
>> 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…
>
> I don't follow how you associate that opinion with implementation of
> scope. I think it's practical and important, and the point is the
> opposite of what you say from my perspective.
> scope is the best approach I've heard to address these differences in
> allocation patterns without asserting any particular policy on the
> user. Escape analysis is the only solution I know to safely allow
> pointers to be passed around without having to worry about how they
> were allocated.
> By contrast, I have no idea what you're suggesting, or how it's not a
> 'crutch'... but if it's anything to do with C++, I'm dubious, and
> kinda frightened.
>
>
> Incidentally, I've recently started a new C++ job, first C++ I've
> written in some years... (after ~18 years, 12 professionally,
> full-time C/C++)
> After having adapted to D and distancing from C++, trying to go back
> is like some form of inhuman torture!
> I really don't remember it being as bad as it is... the time away has
> given me new perspective on how terrible C++ is, and I can say with
> confidence, there is NOTHING C++ could do to make itself a 'better
> option' at this point.
> Judged on common ground, there is no competition. It's only 'the devil
> you know' case that I think can possibly make an argument for C++.

C++14 is quite nice and C++17 will be even better.

Then there is the advantage it is available in all OS vendors SDKs, with very nice tooling.

However, the hard reality in most corporations is that code bases will be pre-C++98 with its own set of guidelines, if any.


--
Paulo

"Manu via Digitalmars-d"  wrote in message news:mailman.1926.1415879071.9932.digitalmars-d@puremagic.com...

> Incidentally, I've recently started a new C++ job, first C++ I've
> written in some years... (after ~18 years, 12 professionally,
> full-time C/C++)
> After having adapted to D and distancing from C++, trying to go back
> is like some form of inhuman torture!
> I really don't remember it being as bad as it is... the time away has
> given me new perspective on how terrible C++ is, and I can say with
> confidence, there is NOTHING C++ could do to make itself a 'better
> option' at this point.
> Judged on common ground, there is no competition. It's only 'the devil
> you know' case that I think can possibly make an argument for C++.

I know, it's easy to forget how bad C++ is to work with.  The new versions have fixed some of the pain points, but only some. 

On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:
> I don't follow how you associate that opinion with implementation of
> scope.

I don't like semantics where I have to state that the parameters and the function should be "pure". It should be opposite. Say, if you have an array on the stack, then I'd like to take a slice of it and send it to a function to compute a sum(). But, I don't want the type system to prevent me from doing it because the author of sum() forgot to add "scope" to the parameter.

What is the difference between a function that is annotated as "pure" and a function where all input is "scope"? This is backwards!

Function signatures should not say "I am playing nice…", that should be the default. They should say "watch out, I'm stealing your stuff!".

> By contrast, I have no idea what you're suggesting, or how it's not a
> 'crutch'... but if it's anything to do with C++, I'm dubious, and
> kinda frightened.

C++ is multi-paradigm and backwards compatible focused, and is therefore ruled by a mess of conventions and fixes, true.

> After having adapted to D and distancing from C++, trying to go back is like some form of inhuman torture!

C++ is not excellent… Too verbose and grown out of the include/macro system (which suits C better than C++). I find C++ ok when I use it like C with bells (and leave out the whistles).

> Judged on common ground, there is no competition. It's only 'the devil you know' case that I think can possibly make an
> argument for C++.

I don't know. I only use C++ for things that is suitable for C. Like DSP/realtime. Fortunately I don't have to deal with other people's C++ code.

Many C++ frameworks look really ugly, but with C++14 I think I shall be able to make my own code look acceptable (readable).

On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim Grøstad wrote:
>
> I don't like semantics where I have to state that the parameters and the function should be "pure". It should be opposite.

Unfortunately for your sanity, this isn't going to happen.  Similarly unlikely is multiple pointer types, which Walter has repeatedly shot down.  I'd suggest bringing it back up if and when discussion of D3 begins in earnest.

-Wyatt

On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:
>> I don't follow how you associate that opinion with implementation of
>> scope.
>
> I don't like semantics where I have to state that the parameters and the function should be "pure". It should be opposite. Say, if you have an array on the stack, then I'd like to take a slice of it and send it to a function to compute a sum(). But, I don't want the type system to prevent me from doing it because the author of sum() forgot to add "scope" to the parameter.
>
> What is the difference between a function that is annotated as "pure" and a function where all input is "scope"? This is backwards!
>
> Function signatures should not say "I am playing nice…", that should be the default. They should say "watch out, I'm stealing your stuff!".

I agree with this in principle, but it is unrealistic for D2. This is stuff that can go into a future D3, together with @safe by default, pure by default, and maybe immutable by default. But that doesn't mean that it shouldn't be introduced in D2 already, so that we can gain experience with it.

That said, it might not be so bad with `scope`. The latest iteration of the proposal has been simplified a lot; scope annotations will mostly be needed for function signatures, and explicit owners are only allowed there. There's also some potential for inference with templates.

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:
>>
>> I don't follow how you associate that opinion with implementation of scope.
>
>
> I don't like semantics where I have to state that the parameters and the function should be "pure". It should be opposite. Say, if you have an array on the stack, then I'd like to take a slice of it and send it to a function to compute a sum(). But, I don't want the type system to prevent me from doing it because the author of sum() forgot to add "scope" to the parameter.
>
> What is the difference between a function that is annotated as "pure" and a function where all input is "scope"? This is backwards!

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.


> Function signatures should not say "I am playing nice…", that should be the default. They should say "watch out, I'm stealing your stuff!".

But that's already a concrete pattern throughout D. To do something otherwise would be an unexpected deviation from the norm.

For the record, I agree with you, but that boat sailed a very long time ago. We must now stick to the pattern that's in place.


> Many C++ frameworks look really ugly, but with C++14 I think I shall be able to make my own code look acceptable (readable).

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.
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!

On 13 November 2014 21:54, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Manu via Digitalmars-d"  wrote in message news:mailman.1926.1415879071.9932.digitalmars-d@puremagic.com...
>
>> Incidentally, I've recently started a new C++ job, first C++ I've
>> written in some years... (after ~18 years, 12 professionally,
>> full-time C/C++)
>> After having adapted to D and distancing from C++, trying to go back
>> is like some form of inhuman torture!
>> I really don't remember it being as bad as it is... the time away has
>> given me new perspective on how terrible C++ is, and I can say with
>> confidence, there is NOTHING C++ could do to make itself a 'better
>> option' at this point.
>> Judged on common ground, there is no competition. It's only 'the devil
>> you know' case that I think can possibly make an argument for C++.
>
>
> I know, it's easy to forget how bad C++ is to work with.  The new versions have fixed some of the pain points, but only some.

Yeah... nar. Not really. Every line of code is at least 3-4 times as
long as it needs to be. It's virtually impossible to see the code
through the syntactic noise.
I like nullptr, I can get behind that ;)

I realised within minutes that it's almost impossible to live without slices.
On the plus side, I've already made lots of converts in my new office
from my constant ranting :P

On Thursday, 13 November 2014 at 10:38:57 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
>> 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).

I think I understand now how you want to use templates. You basically want to make the various reference types implement a protocol, and then templatize functions to accept any of those reference types, just like we do with ranges.

But this brings with it the downside of templates, namely template bloat. And you need to do additional work to eliminate all the redundant inc/dec calls if you pass an RC reference. All of which is unnecessary for most functions, because a function knows in advance whether it needs to retain the reference or just borrow it, and can be declared accordingly. This means that `scope` acts as an abstraction over the various reference types, be it GC, RC, plain pointer, unique pointer, or some more complicated user defined scheme.

This also benefits the GC, by the way. A scope reference doesn't need to be treated as a root, because there will always be at least one other copy of the reference. This means that structures containing only scoped references need not be scanned.

>
>>> 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.

Yes. But they can also be merged into un-owned structures (i.e. the various heaps), at which point they lose their owned-ness. This allows the creator of these objects to be agnostic about how the consumers want to handle them.

> I think region allocators do better if you start constraining relations by ownership.

Not sure what you mean, but I don't think region allocators can be used for this. They require the object creator to know in advance how long the objects will exist. Or alternatively, the creators need to be informed about that by receiving a reference to the region allocator, at which point we're most likely back at templates.

On 11/13/14 1:41 AM, bearophile wrote:
> 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.

In fact I am not! -- Andrei