shared - i need it to be useful

[Stanislav Blinov]

On Sunday, 21 October 2018 at 19:22:45 UTC, Manu wrote:
> On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via 
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:

>> Because the whole reason to have `shared` is to avoid the 
>> extraneous checks that you mentioned above,
>
> No, it is to assure that you write correct not-broken code.

You can do that without `shared`.

>> and only write actual useful code (i.e. lock-write-unlock, or 
>> read-put-to-queue-repeat, or whatever), not busy-work (testing 
>> if the file is open on every call).
>
> `shared` is no comment on performance. You have written a slow 
> locking API.
> If you care about perf, you would write a completely different 
> API that favours perf.
> This not impossible, nor even particularly hard.

You're conflating your assumptions about the code with the topic 
of this discussion. I can write a million examples and you'll 
still find a million reasons to talk about how they're 
incorrectly implemented, instead of focusing on merits or 
disadvantages of your proposal with the code given as is.

>> If you have a `shared` reference, it better be to existing 
>> data.
>
> I mean, if I dereference a pointer, it had better not be null!

Why would you share a null pointer?

>> That's why having `shared` and un-`shared`
>> references to the same data simultaneously is not safe: you 
>> can't guarantee in any way that the owning thread doesn't 
>> invalidate
>> the data through it's non-`shared` reference while you're doing
>> your threadsafe `shared` work; you can only "promise" that by
>> convention (documentation).
>
> The owning thread is not a special actor. Your reasoning is 
> wonky here.

Why have it then at all? If it's not a "special" actor, just make 
all shared data `shared`. But your proposal specifically targets 
the conversion, suggesting you *do* need a special actor.

>> And I have partially-read or partially-written data.
>
> I expect you flushed before killing the file.

So? The threads still weren't done yet.

>> Or Maybe I call closeFile(), main thread continues and opens 
>> another file,
>> which gives the same file descriptor, `shared` references to
>> FileHandle which the user forgot to wait on continue to work
>> oblivious to the fact that it's a different file now.

> It's wild to suggest that ANY design for `shared` should 
> somehow deal with the OS recycling a file handle...

I'm not suggesting that at all, you've completely misrepresenting 
what I'm saying by splitting a quote.

> And it's still not an un- at safe crash! It's just a program with 
> a bug.

Ok, if you say that sticking @safe on code that can partially 
piece together data from unrelated sources is fine, then sure.

>> > I'm going to assume that `shareWithThreads()` was implemented
>> > by an 'expert' who checked the function results for errors...

>> But you can only find out about these errors in 
>> `waitForThreads`, the very call that the user "forgot" to make!
>
> ...what?

Please suggest another way of handling errors reported by other 
threads. More `shared` state?

>> [ ... snip ... ]
>
> You have to concede defeat at this point.

I agree. No matter how hard I try or how many times I ask you to 
demonstrate, I still fail to see the value in assuming @safe 
implicitly conversion of mutable data to shared. Instead of 
defending your proposal, you chose to attack the opposition. 
You've defeated me, flawless victory.

> Destroy my proposal with another legitimately faulty program.

Is there a point? I post code, you: "nah, that's wrong". Steven 
posts code, you: "nah, that's wrong". Timon posts code, you: 
"nah, that's wrong". Walter posts code, you: "nah, that's 
wrong"... What's right then?