On Wednesday, 11 September 2019 at 20:46:46 UTC, ag0aep6g wrote:
>
> The shorthand is defined to be equivalent to the longhand, and the longhand works, so the shorthand also works. You don't even have to mention it in the DIP. It's already in the spec.

I agree, changes have to be done though. Meaning, it should
not focus on alias declaration, it should be more general.

>
> I feel like working on the (concrete) syntax level is too low-level.
>
> I think it's obvious that the new feature should be applied after lexing and parsing. You don't want to write your DIP in terms of characters or keywords.
>
> To me, it also seems obvious that the new feature should be applied after shorthand and longhand syntaxes have been consolidated. I'd expect that the parser already does this, but I'm not sure.
>
> Beyond that, I'm not knowledgeable enough to say when it should happen. If the shorthand/longhand consolidation is not done by the parser, and not in some very early semantics phase either, then that might make things complicated.
>

It's not the syntactic part the problem, meaning parsing
and lexing. It's the rewriting capabilities of templates.
Check Description -> New (in bold) in the DIP.
_However_, it's obvious that these rewriting problems don't
apply only to alias declarations. Actually, they're borrowed
from templates. AFAIK, these rewriting capabilities are
not as formally described as they could, but it was not
the initial intention of this DIP to describe and it won't
be now.

What I mean is that it seems feasible to describe the resolution
pretty much the same way for both long-hand and short-hand.

>> And it's not clear whether I will have the time to do this.
>
> That's perfectly understandable. No one (in their right mind) is going to blame you, if you don't manage to push this all the way.
>
> It's a hard problem. The oldest Bugzilla issue for it is over a decade old, with a dozen or so duplicates. Fixing/implementing that kind of issue isn't usually a walk in the park, or someone would already have done it.

Indeed, although now it might be possible. When I was experimenting with this,
the implementation seemed quite complicated indeed. So, I left it in a draft
stage where I hope will be a good starting point or at least give an idea.
(It actually solves the use cases that the people who wanted the feature
are interested. That includes the cases in any issue report I had seen).
Instead, I focused on describing the feature as completely as possible, which
should help both the implementation and the consistency of the feature.

On Wednesday, 11 September 2019 at 22:30:31 UTC, Stefanos Baziotis wrote:
> [snip]

Another example of where something like what I had suggested above with constrained aliases might be useful.

For whatever dumb reason, I was just playing around with restricting Algebraic to only allow numeric types. You have to create a new struct and add in some member functions to get it to work. You can do more-or-less the same thing with an alias, easier IMO, but then if a function calling that alias doesn't work as easily (for reasons discussed above in thread).

import std.variant;
import std.traits : isNumeric;
import std.meta : allSatisfy;

struct Foo(T...)
    if (allSatisfy!(isNumeric, T))
{
    Algebraic!(T) x;
    alias x this;

    this(U)(U val) {
        x = val;
    }

    void opAssign(U)(U val) {
        x = val;
    }
}

template Bar(T...)
    if (allSatisfy!(isNumeric, T))
{
    alias Bar = Algebraic!(T);
}

void useFoo(T...)(Foo!T x) {

}

void useBar(T...)(Bar!T x) {

}

void main() {
    import std.stdio : writeln;

    auto v = Foo!(int, double)(5);
    writeln(v.peek!(int));
    writeln(v);
    v = 3.14;
    writeln(v.peek!(double));
    writeln(v);

    auto w = Bar!(int, double)(5);

    useFoo(v);
    //useBar(w); //does not compile currently
}

On Monday, 30 September 2019 at 19:16:47 UTC, jmh530 wrote:
> On Wednesday, 11 September 2019 at 22:30:31 UTC, Stefanos Baziotis wrote:
>> [snip]
>
> Another example of where something like what I had suggested above with constrained aliases might be useful.
>

Thanks for the info. It happened that just yesterday I updated the DIP
and when Mike finds a slot, we'll either move to round 2 or final.
I believe that most of the problems discussed in this thread have been
solved by abstracting the terminology. I think it's better to not discuss
further here as a summary has already been written.
But please feel free to drop a comment on the new thread, when it is posted.

Best regards,
Stefanos