Am Mon, 12 Oct 2015 10:28:55 +0300
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 10/12/15 7:19 AM, Jonathan M Davis wrote:
> > On Monday, 12 October 2015 at 03:59:04 UTC, Marco Leise wrote:
> >> Am Sun, 11 Oct 2015 07:32:26 +0000
> >> schrieb deadalnix <deadalnix@gmail.com>:
> >>
> >>> In C++, you need to assume things are shared, and, as such, use thread safe inc/dec . That means compiler won't be able to optimize them. D can do better as sharedness is part of the type system.
> >>
> >> With the little nag that `shared` itself is not fleshed out.
> >
> > Well, it really should be better fleshed out, but the reality of the matter is that it actually works pretty well as it is. The problem is primarily that it's a pain to use - and to a certain extent, that's actually a good thing, but it does make it harder to use correctly.
> 
> Yah, I'd like to make "finalizing the language" a priority going forward, and finalizing shared is a big topic. It's hard to present to the world a language with fuzzy corners. -- Andrei

Wouldn't it be great if everyone took notes of the currently
perceived shortcomings of shared so that there is a pile of
use- and corner-cases to look at for a redesign?
Then you would filter by valid use case and undesired usage and
practically had everyone's input already under consideration
when it hits the discussion forums.
My own experience is what Jonathan describes. It is annoying
in a good way. It makes you wait and think twice and more
often than not you really attempted an illegal access on shared
data. This went well up to a point when I had a component that
held references to shared things. There is no such thing as a
shared struct with shared fields in the type system. Once you
share the outer struct, the inner stuff's shared status is
merged with the outer and you can't cast it back to what it
was before. So it works for plain integral types, but
aggregates and what others mentioned about thread
local GC heaps are my big question marks.

-- 
Marco

On 10/12/2015 06:49 PM, Andrei Alexandrescu wrote:
> Experience with Rust is still young, but there seems to have already
> been a backlash; programmers try it and it's just too arcane to use
> in constant preoccupation about them ownership rules. ...

> Copying linear types and going whole-hog stealing the ownership system
> from Rust doesn't sound like the best strategy to Walter and myself.

D can do ownership without copying the details of the Rust way. I think that Marc's point was that basic similarities should be allowed, because the design space isn't that vast.

> At least one PL researcher whose opinion I trust believes linear types
> don't have a future.

We already have linear types. (@disable this(this)).

> D has its own context and its own approach to matters. I believe creative
> solutions are possible that achieve much of what we need without going
> the Rust way, which seems not appropriate for us.

What do we need?

On 10/13/15 3:09 AM, Timon Gehr wrote:
> On 10/12/2015 06:49 PM, Andrei Alexandrescu wrote:
>> Experience with Rust is still young, but there seems to have
>> already been a backlash; programmers try it and it's just too
>> arcane to use in constant preoccupation about them ownership rules.
>> ...
>
>> Copying linear types and going whole-hog stealing the ownership
>> system from Rust doesn't sound like the best strategy to Walter and
>> myself.
>
> D can do ownership without copying the details of the Rust way. I
> think that Marc's point was that basic similarities should be
> allowed, because the design space isn't that vast.
>
>> At least one PL researcher whose opinion I trust believes linear
>> types don't have a future.
>
> We already have linear types. (@disable this(this)).

That much is not too complicated.

>> D has its own context and its own approach to matters. I believe
>> creative solutions are possible that achieve much of what we need
>> without going the Rust way, which seems not appropriate for us.
>
> What do we need?

Next paragraph after the one you quoted:

> BTW where we want to be is: expressive reference counting without
> loss of @safe-ty and hopefully good uniqueness control again with
> @safe-ty and possibly a bit of compiler help.


Andrei

On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload wrote:
> On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
>> I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that.
>>
>> Maybe you should take a break from programming for a while and work on your attitude?
>>
>> While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something!
>
> Dude you are kind of being a jerk. He's just arguing against, rather passionately, a design decision he thinks is poor. It values no one if individuals remain quiet and conform. Certainly not the leadership. What you see as arrogance is really just passion.

Passion or not,

"If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad."

That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but since I don't know, I'll just assume it's false and assume you are wrong.".

That's not very logical. Why wouldn't he just as well assume X is true?

The fact is, he can't and shouldn't make such statements about X if he has no "evidence" about it.

Instead, wouldn't the proper approach be to discuss, learn, and share what one things in a positive way so everyone can learn about X and reach a more intelligent understanding of it?

Hilter was very passionate too, are you saying he was right?

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
> On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload wrote:
>> On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
>>> I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that.
>>>
>>> Maybe you should take a break from programming for a while and work on your attitude?
>>>
>>> While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something!
>>
>> Dude you are kind of being a jerk. He's just arguing against, rather passionately, a design decision he thinks is poor. It values no one if individuals remain quiet and conform. Certainly not the leadership. What you see as arrogance is really just passion.
>
> Passion or not,
>
> "If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad."
>
> That statement shows a lot of arrogance.
>
> It he not really just saying "I have no clue if X is true, but since I don't know, I'll just assume it's false and assume you are wrong.".
>
> That's not very logical. Why wouldn't he just as well assume X is true?

The context is that all additions have an intrinsic cost because they increase complexity and restrict future design choices, therefore the onus is on any change/addition to justify its value in order to overcome that cost.

I think you are completely misreading the situation, or trolling. This is just

On Monday, 12 October 2015 at 19:35:34 UTC, Marco Leise wrote:
> Wouldn't it be great if everyone took notes of the currently
> perceived shortcomings of shared so that there is a pile of
> use- and corner-cases to look at for a redesign?

The problem with shared is that shared should not be constant over time, it should be related to behavioural typing/type state.

Synchronization is a temporal factor not a static typing factor.

On Monday, 12 October 2015 at 08:10:44 UTC, deadalnix wrote:
> Ok, I'll write a DIP.

That would be great to see.  N.B. it's not only about Walter and Andrei: with a detailed, written-up proposal in place, the rest of us can examine it and, assuming we like it, lend our vocal support to the idea.

On 12 October 2015 at 16:02, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> DIP69 is obviously known to me because my name is on it.

What is the problem with DIP69? It looks like a great direction to me.
It's almost exactly what I've been begging for for years!
As long as methods can overload on scope, then it can be used to
implement efficient RC. Also many other situations are improved in
general.

The only thing there that's not clear to me from DIP69 is:
  scope ref T func(scope ref T x) { return x; }

This needs to work, or you can't chain... but it doesn't look like it's addressed?

On Tuesday, 13 October 2015 at 12:40:46 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 October 2015 at 19:35:34 UTC, Marco Leise wrote:
>> Wouldn't it be great if everyone took notes of the currently
>> perceived shortcomings of shared so that there is a pile of
>> use- and corner-cases to look at for a redesign?
>
> The problem with shared is that shared should not be constant over time, it should be related to behavioural typing/type state.
>
> Synchronization is a temporal factor not a static typing factor.

That said, if you have:

1. writer-ownership as a feature
2. mark variables as "only writable by one owner"

Then the compiler can drop some read locks for the _owning_ thread.

But D does not have ownership as a feature beyond "thread local memory"?

On Tuesday, 13 October 2015 at 13:02:43 UTC, Ola Fosheim Grøstad wrote:
> That said, if you have:
>
> 1. writer-ownership as a feature
> 2. mark variables as "only writable by one owner"
>
> Then the compiler can drop some read locks for the _owning_ thread.
>
> But D does not have ownership as a feature beyond "thread local memory"?

I think the D designers should take a long and hard look at Pony:

isolated: deny global read/write, deny local read/write
transition: deny global read/write, deny local write
reference: deny global read/write
value: deny global write, deny local write
box: deny global write aliases
tag: allow all aliases

_loosely_ translated:

isolated: void*
transition: const T*
reference: T*
value: immutable T*
box: globally as shared const T*, locally as shared T*
tag: shared T*

So D lacks some way to express the "box" type?