Struggling to implement parallel foreach...

Manu turkeyman at gmail.com
Mon Jun 17 22:42:23 UTC 2019


On Tue, Jun 18, 2019 at 5:40 AM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 17.06.19 12:18, Nicholas Wilson wrote:
> >
> > That is all moot if mutable promotes to shared under "New Shared"™,
>
> I was discussing the current language. And even then, with old shared as
> well as new shared, my interpretation is the correct one.
>
> What "New Shared" it is actually trying to do is to introduce a new
> `threadsafe` qualifier. This doesn't conflict with `shared`. Roughly
> speaking, `threadsafe` is to unshared and `shared` what `const` is to
> mutable and `immutable`.
>
> threadsafe(int) <- inaccessible
> threadsafe(shared(int)) <- same as shared(int), accessible

If this threadsafe concept is something that exists, I am not a party
to any such conversation.

There was some discussion about promotion possibility (but that never
talked about 'threadsafe'), and that was universally rejected.

Making shared inhibit read/write needs to happen regardless of
anything else to work according to current rules.

> The "New Shared" vision is to remove type qualifier support for `shared`
> and to instead move `shared` into druntime in a restricted form. (Last
> time I discussed this with Manu, I believe he was adamant that the
> language shouldn't distinguish between shared and unshared data at all,
> so we had a long unproductive debate.)
> Then `shared` is repurposed to mean something completely different.

I don't know what you're talking about.
Shared needs to have read/write access removed... I feel like that was
universally agreed.
>From there, I can get to work.

> > I don't think anybody disagrees that qualified local functions should
> > work.
>
> Yes, they do. Manu said you shouldn't be able to call an
> `immutable`-qualified local function! This is extremely weird, because
> it is always valid to drop a context qualifier!
>
> > It would be useful to decouple this from the the current
> > discussion to avoid derailing.
>
> I think it's related to why Manu is so confused.

I don't think I'm as confused as you'd like to think. I understand I'm
proposing to obliterate a thing. It's a complex and surprising thing,
and as far as I can tell, it's useless, and only a point of friction
and bugs. Can you show how it's useful?

> Basically, there are two cases for local context qualifiers:
>
> 1. can implicitly promote mutable variable (`const`, `threadsafe`/"New
> Shared")
> 2. cannot implicitly promote mutable variable (`immutable`, (old) `shared`).
>
> So far, Manu only understands case 1, because there is a crutch: it can
> be interpreted by creating a local context struct containing all local
> variables in the stack frame, of which the local function is a method.
> But case 2 exists even if we move from `shared` to `threadsafe`. Because
> Manu only understands case 1, he considers the fact that `shared` ->
> `threadsafe` /"New Shared" is a move from case 2 to case 1 as evidence
> that old shared is broken while `threadsafe`/"New Shared" is not.
>
> This is the argument that is complete nonsense that I am so annoyed
> about, because it leads to `immutable` capturing not working for no
> reason at all! Skip step 1, where you break local function qualifiers.

Show me one example of an immutable local function in the wild;
explain how it's useful? It's a meaningless concept; how can a
functions capture be immutable? We have no language to qualify the
capture, and certainly not immutable; the callstack is mutable.

But I said before, solve however you like.



More information about the Digitalmars-d mailing list