On Tuesday, 13 April 2021 at 00:14:38 UTC, Timon Gehr wrote:

That sounds a lot like generics (in the sense of Java or C# generics). At least, it's very similar. I'd be glad if generics were introduced to D. The only language I know of that has templates and generics is C++/CLI. The main practical advantage of generics over templates is that if your generic construct compiles, it'll be type-correct for any arguments a user would supply. Unlike templates, generics never fail on instantiation.

Attribute polymorphism as I understand you is that you have variables for attributes so that for every attribute, there's a separate "type" of variable, like @safe-ty a such that a can be applied as an attribute to stuff that can carry one.

Giving D any kind of polymorphism (half-baked inout aside) would be a major language change.

As I understand you, inout is a fixed-name qualifier variable and your sense is that it's broken in D, because one can only have one of them. I guess that was a design choice. I cannot estimate the extent of how conscious that decision was. Probably no one had a use-case in mind that really required more than one qualifier variable so inout sufficed.

Could also be that you mean the fact that one cannot have Array!(inout int) f(Array!(inout int)). Unfortunately, inout is weird in many ways.

int x;
auto dg = (int* update) {
    if (update) x = *update;
    return x;
};

Associated is a concept in ones head, not a definition by the language. It is what Jonathan Davis described in this article as "the object's state could actually live outside of the object itself and be freely mutated even though the function is const".

Qualifiers and attributes have an idea behind them, but when it comes to practical use, there's often a compromise. Set debug blocks aside, set slices' capacity being marked pure aside, the fact that allocating objects (including arrays) is pure is a deliberate and explicitly stated decision that could easily be argued against: If f(n) is a pure operation, (where n is a mere int, just to be clear) how could it happen that if I do it twice, it succeeds once and fails the second time? But allocating a large amount of memory can amount to exactly that. There are deliberate boundaries to any concept. I have no idea of the state of __metadata, but it would be another one. __metadata would be to const what @trusted is to @safe.

Completely surprising behavior and a breaking change.

import std.concurrency;
void main(){
    int x;
    // this conversion should not go through
    shared(int delegate(int*)) dg = (int* update) {
        if (update) x = *update;
        return x;
    };
    spawn((typeof(dg) dg) {
        int y = 3;
        dg(&y); // this should not be callable
    }, dg);
    import std.stdio;
    writeln(x);
}

What if shared on the outer of dg wouldn't matter, but it being missing on the context annotation does? Then dg(&y) wouldn't be the problem, but spawn just cannot take delegates with mutable non-shared contexts.

I get that it is theoretically sound to extend shared of shared(int delegate(int*)) to make it identical to shared(int delegate(int*) shared). The same way it was theoretically sound in C++11 to define that constexpr member functions are also const member functions. (They removed that rule in C++14 which was a breaking change.)
To stick to D, it sounds as unpractical as only allowing const on variables of types that only have const member functions.

As I explained above, qualifiers and attributes have practical limits and I do think this is one. It's not like we cannot express a shared context on a delegate type.

C delegate(A) compose(A, B, C)(const C delegate(B) f, const B delegate(A) g) pure
{
    return a => f(g(a));
}

auto compose(F : C delegate(B), G : B delegate(A), A, B, C)(F f, G g) pure
{
    return delegate C(A arg) => f(g(arg));
}

Ugly is opinion. On that basis, almost every template is a workaround for lack of this or that kind of polymorphism.
It's only ugly on the first glace. Apart form the delegate C part, it contains the bare minimum to express itself. One could leave out the : Y delegate(X) parts, too.
I like to have expectations spelled out in code. That's a personal preference, I guess.

Of course. Unless you have attribute polymorphism you need templates. If you don't use them, in the current state, you can have all attributes you want on your input delegates, you have to specify one set of attributes on the return type. So you need attribute polymorphism and type polymorphism, because without them together, you still need templates. Then you can just use templates.
Practically speaking, if your types are concrete so you don't need template type parameters, it's very likely that the attributes are concrete, too, removing the need for attribute polymorphism.
The requirement of being compositional could be unwarranted.

Depends on how you interpret transitivity. Being practical is also a design goal. In contrast to e.g. C++, D doesn't "trust the programmer". I'm not advocating a "trust the programmer" solution (at least I'm convinced I'm not). In my estimation, I advocate a practical solution that minimizes language change.

I don't. And I was wrong about the DIP part. It's the other way around because it's a breaking change.