Generality creep

[Nicholas Wilson]

On Sunday, 31 March 2019 at 11:30:08 UTC, Andrei Alexandrescu 
wrote:
> The necessity to work on shared was also present in the January 
> 2015 vision document (https://wiki.dlang.org/Vision/2015H1): 
> "Nail down fuzzily-defined areas of the language (e.g. shared 
> semantics, @property)."
>
> Writing it down doesn't get it done.

Indeed thats why its on the AGM.

> Defining shared properly would take a team with a programming 
> languages expert, a threading expert, and an application 
> expert. (Some roles may be realized within the same person.) I 
> know people within our community with the required expertise.

c.f. DIP1000? I don't think you or Walter are memory safety 
experts, and despite the issues that occurred with the 
implementation (and documentation(!)) process (hindsight is 
20/20), what you have achieved is quite remarkable: a blacklisted 
(bad things are disallowed), inductive (if all the the code I 
call is @safe and nothing I do is on the blacklist, then so am I) 
model of memory safety that works!

What Manu has (tried to, somewhat unsuccessfully) argue for is 
the same approach to thread safety with shared: tie the correct 
use of shared to @safe/@system/@trusted, enforce the correct use 
of user defined and verified (i.e. @trusted) thread safe 
primitives. Then shared (as a function parameter attribute) in 
@safe code becomes a requirement to act in a thread safe manner 
with that argument under the above framework.

No-one is expecting to get the implementation perfect first time, 
we will miss important details, and thats OK. We fix them, 
document them (this is the single biggest problem with the way 
DIP1000 was developed and the reason PRs were stalled) and move 
on with the satisfaction that the implementation is better than 
it was before.

> But I don't know any who'd also have the time to embark on this.

If the foundations can be set out, pre-approved, with sufficient 
clarity at dconf, then I'm confidant we can get to the point 
where we can iteratively improve it. Who knows, Timon might 
implement the whole thing in the hackathon.

I don't think it will be as hard as it seems to get somewhere 
useful. We already have @safe/@system/@trusted, shared is already 
a thing (albeit not very useful currently), all we need to do is 
define the blacklist and how the induction should work. Again, 
they don't need to be perfect first time.

> I got burned out on writing vision documents (Walter was never 
> a fan so I did them all) because it was difficult to figure 
> their impact. Contributors asked for a vision document. So we 
> started one. Then contributors continued doing what they were 
> doing.

I understood vision documents to set out the intended direction 
of the DLF, irrespective of what contributors are doing, of 
course they're going to continue to do what they were doing, that 
what volunteers do. To me they were more like a politicians 
promise (apologies for the analogy), a statement of intention, 
and if it doesn't match up to reality, then its no big deal as 
long as progress is still being made, the next one is written to 
take that into account with its projections.

Anyway enough about what they were. What they will become is a 
byproduct of the minutes of the AGM / quarterly meetings, they 
will practically write themselves.
If we have more (corporate) participation in them (as I hope) 
then chances are they will reflect reality to a much high degree 
of fidelity.