On Thursday, 29 October 2020 at 14:39:31 UTC, H. S. Teoh wrote:
> On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: [...]
>> D frequently allows no-op attributes.
> [...]
>
> I find that to be a bad smell in terms of language design, actually. Either something should be allowed and have a definite effect, or it should not be allowed.  Not this murky grey area where you can write something and it seems to be allowed, but doesn't actually have any effect.

Yes, but that is a tough call. Do you want to catch unintended programmer errors or do you want to make it as easy as possible to write generic code? I'm in favour of max strictness, but then you need to keep the feature set down and make sure it is uniform and orthogonal.

But I think it is a bit sad that "shared" isn't enforced so that it could lead to actual benefits. Like requiring that globals are typed shared and enable thread local garbage collection. E.g. GC allocation of non-shared should be on a thread local heap and anything shared should be on a global heap.

On Thu, Oct 29, 2020 at 4:13 PM H. S. Teoh via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

>
> But why can't that be treated differently from explicitly writing @safe on a declaration?  I mean, yeah, it's easier to implement the compiler that way, but ease of implementation shouldn't count against proper language design!
>
>
> T
>
> --
> Doubt is a self-fulfilling prophecy.
>

But what about this:

shared {
    some_ type some_var;
    immutable int x = 1;
}

There are many ways to define it and last time when I was looking at how
this is implemented in D frontend it was implemented as a bitmask variable
and you have no context from where it comes.
So only way would be to disallow this within lexer which I do not see as a
good options

On Thursday, 29 October 2020 at 16:45:51 UTC, Ali Çehreli wrote:

>
> immutable string p;
>
> shared static this() {
>   p = environment["PATH"];  // <-- Run time
> }
>

Immutable static variables being implicitly non-thread-local is a design mistake. Thread-local immutable variables have the same right to exist as immutable class/struct instance fields.

This should be possible without hacks:

immutable int val; // thread-specific value

static this() {
    val = ...;
}


...because it is logically the same as:

struct V {
    immutable int val;
}

V val;

static this() {
    val = V(...);
}