On Sunday, 26 July 2020 at 02:10:19 UTC, Andrei Alexandrescu wrote:
> On 7/25/20 9:44 PM, Adam D. Ruppe wrote:
>> However I'm going to point out that my trick doesn't work if you are trying to forward a template, since template params cannot be introspected. As far as I know, there is no solution to that.
>
> That needs fixed. What primitives would you need for that?

I need it to support open method templates.

On 7/26/20 8:19 AM, Andrej Mitrovic wrote:
> On Sunday, 26 July 2020 at 11:56:16 UTC, Jacob Carlborg wrote:
>> On 2020-07-26 04:10, Andrei Alexandrescu wrote:
>>
>>> That needs fixed. What primitives would you need for that?
>>
>> It has already been implemented but rejected [1]. Andrei, you were part of the discussions and approved the changes.
>>
>> [1] https://github.com/dlang/dmd/pull/5201
> 
> Ah, this was in the back of my head when someone mentioned template parameters.
> 
> I haven't looked at that in a long time.

Well... would you like to revive it?

On Monday, 27 July 2020 at 14:08:30 UTC, Andrei Alexandrescu wrote:
> On 7/26/20 8:19 AM, Andrej Mitrovic wrote:
>> On Sunday, 26 July 2020 at 11:56:16 UTC, Jacob Carlborg wrote:
>>> On 2020-07-26 04:10, Andrei Alexandrescu wrote:
>>>
>>>> That needs fixed. What primitives would you need for that?
>>>
>>> It has already been implemented but rejected [1]. Andrei, you were part of the discussions and approved the changes.
>>>
>>> [1] https://github.com/dlang/dmd/pull/5201
>> 
>> Ah, this was in the back of my head when someone mentioned template parameters.
>> 
>> I haven't looked at that in a long time.
>
> Well... would you like to revive it?

One question that was brought up recently by an unrelated DMD PR [1] was whether new traits require a DIP. None of the traits we added in the past few years have gone through the DIP process as far as I remember. Of course, going through the DIP process can only improve the quality, but on the other hand, one could argue that it would make things unnecessary hard for easy additions like isDeprecated [2] and isDisabled [3].

How high should the bar be? Should we decide on a case-by-case basis?

[1]: https://github.com/dlang/dmd/pull/11442#issuecomment-661996482
[2]: https://github.com/dlang/dmd/pull/7178
[3]: https://github.com/dlang/dmd/pull/7569

On 7/27/20 11:57 AM, Petar Kirov [ZombineDev] wrote:
> On Monday, 27 July 2020 at 14:08:30 UTC, Andrei Alexandrescu wrote:
>> On 7/26/20 8:19 AM, Andrej Mitrovic wrote:
>>> On Sunday, 26 July 2020 at 11:56:16 UTC, Jacob Carlborg wrote:
>>>> On 2020-07-26 04:10, Andrei Alexandrescu wrote:
>>>>
>>>>> That needs fixed. What primitives would you need for that?
>>>>
>>>> It has already been implemented but rejected [1]. Andrei, you were part of the discussions and approved the changes.
>>>>
>>>> [1] https://github.com/dlang/dmd/pull/5201
>>>
>>> Ah, this was in the back of my head when someone mentioned template parameters.
>>>
>>> I haven't looked at that in a long time.
>>
>> Well... would you like to revive it?
> 
> One question that was brought up recently by an unrelated DMD PR [1] was whether new traits require a DIP. None of the traits we added in the past few years have gone through the DIP process as far as I remember. Of course, going through the DIP process can only improve the quality, but on the other hand, one could argue that it would make things unnecessary hard for easy additions like isDeprecated [2] and isDisabled [3].
> 
> How high should the bar be? Should we decide on a case-by-case basis?
> 
> [1]: https://github.com/dlang/dmd/pull/11442#issuecomment-661996482
> [2]: https://github.com/dlang/dmd/pull/7178
> [3]: https://github.com/dlang/dmd/pull/7569

Thanks for asking. I'm no longer in the decision loop but here's what I think. There'd be somewhat obvious traits to have ("is this symbol deprecated?") and traits that work together toward a larger goal, such as perfect forwarding or general introspection itself. In the former case acceptance could and should be somewhat quick, whereas in the latter case we risk having a hodge-podge of traits that don't combine properly to attain the initial goal. In a way we're there right now - we added traits on a need basis and we're unclear on what the limits of what we can and what we can't do, or how to do it.

On Monday, 27 July 2020 at 21:08:52 UTC, Andrei Alexandrescu wrote:
> [..]
>
> Thanks for asking. I'm no longer in the decision loop but here's what I think. There'd be somewhat obvious traits to have ("is this symbol deprecated?") and traits that work together toward a larger goal, such as perfect forwarding or general introspection itself. In the former case acceptance could and should be somewhat quick, whereas in the latter case we risk having a hodge-podge of traits that don't combine properly to attain the initial goal. In a way we're there right now - we added traits on a need basis and we're unclear on what the limits of what we can and what we can't do, or how to do it.

So the question is what do we do about the new traits proposed by [1]? How formal does the process needs to be about them? I see 3 options:
1. Traits or otherwise any language features part of a larger story (e.g. template parameter introspection, perfect forwarding) need to go through a 2 step DIP process:
  1) A strategic/vision DIP that states the high-level problem that we want to solve. The goal of this DIP would be form community and leadership consensus on whether something is a strategic goal for D and whether we need to solve it.
  2) A tactical DIP that proposes concrete language features and defines their semantics. In this case these would be the traits proposed by [1].

2. The language maintainers (Atila and Walter) decide on each DMD PR on a case-by-case basis.

3. New traits that haven't gone through a DIP process are considered experimental and can be added behind a compiler switch (which either enables all experimental traits, or each one individually). Such traits continue to have experimental status for several releases until we gather real-world experience and we decide to either remove, change, or to stabilize them (make them generally part of the language and available without any switch).
Unlike 2. any dmd contributor (or perhaps a group of minimum of 2/3 people?) with write access to the dmd repo can decide to merge such experimental traits, after some minimal requirements are met, such as a changelog entry and sufficiently thorough test(s) that demonstrate the usefulness of the feature and cover all knownedge edge cases (e.g. each added error message is tested).

@Andrei @Atila @Walter what do you guys think?

[1]: https://github.com/dlang/dmd/pull/5201

On Tuesday, 28 July 2020 at 05:34:59 UTC, Petar Kirov [ZombineDev] wrote:
> @Andrei @Atila @Walter what do you guys think?
>
> [1]: https://github.com/dlang/dmd/pull/5201

The community (and maintainers) need to settle on the desired set of traits, and then we can think about how to best implement it.

I'm sure the PR is very outdated by now, there's probably better ways of implementing it.

On Sun, Jul 26, 2020 at 11:30 AM Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> This topic came about during beerconf (it was fun!): Write an idiomatic
> template `forward` that takes an alias `fun` and defines (generates) one
> overload for each overload of `fun`. Example:
>
> template forward(alias fun)
> {
>      ...
> }
>
> Now for this function:
>
> void myfun(int, ref double, out string);
> int myfun(in string, inout double);
>
> the instantiation would be (stylized):
>
> template forward!myfun
> {
>      void myfun(int a, ref double b, out string c)
>      {
>          return myfun(a, b, c);
>      }
>      int myfun(in string a, inout double b)
>      {
>          return myfun(a, b);
>      }
> }
>
> So the challenge is implementing forward() to do this.
>

As someone who's been doing exactly this repeatedly basically-forever, I
can say the exercise is absolutely no fun at all.
It is my opinion that if the solution involves a text-mixin, the author
gets an instant FAIL.
The major hangup in this exercise is dealing with 'storage class', which is
impossible because it's not part of the language, and instantly forces
synthesising strings.
Forwarding the default args is tricky; and I've never managed to produce a
uniform solution that doesn't suffer some edge cases, but I've always made
it work for the specific set of things I'm wrapping.

Template arg forwarding is another level above, but I think that should be taken as a secondary matter. Solve for normal functions first, and then maybe there's a hope.

On Tuesday, 28 July 2020 at 22:48:16 UTC, Manu wrote:
> It is my opinion that if the solution involves a text-mixin, the author gets an instant FAIL.

But:

> The major hangup in this exercise is dealing with 'storage class', which is
> impossible because it's not part of the language, and instantly forces synthesising strings.

Guaranteed failure then? ;-)

On Wed, Jul 29, 2020 at 9:40 AM Jean-Louis Leroy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 28 July 2020 at 22:48:16 UTC, Manu wrote:
> > It is my opinion that if the solution involves a text-mixin, the author gets an instant FAIL.
>
> But:
>
> > The major hangup in this exercise is dealing with 'storage
> > class', which is
> > impossible because it's not part of the language, and instantly
> > forces synthesising strings.
>
> Guaranteed failure then? ;-)
>

Yes.

On Wednesday, 29 July 2020 at 10:38:29 UTC, Manu wrote:
> On Wed, Jul 29, 2020 at 9:40 AM Jean-Louis Leroy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 28 July 2020 at 22:48:16 UTC, Manu wrote:
>> > It is my opinion that if the solution involves a text-mixin, the author gets an instant FAIL.
>>
>> But:
>>
>> > The major hangup in this exercise is dealing with 'storage
>> > class', which is
>> > impossible because it's not part of the language, and instantly
>> > forces synthesising strings.
>>
>> Guaranteed failure then? ;-)
>>
>
> Yes.

This is a problem I spent a lot of time on while trying to support all the variations of functions in openmethods (and the problem is even harder because I need to alter the storage classes of a subset of the parameters).

Doesn't this cut it?

module challenge;

template forward(alias fun)
{
    import std.format;
    import std.traits;
    enum name = __traits(identifier, fun);
    static foreach (ovl; __traits(getOverloads, __traits(parent, fun), name)) {
        mixin(q{
                auto ref %s(Parameters!ovl args) {
                    return __traits(parent, fun).%s(args);
                }
            }.format(name, name));
    }
}

void myfun(int, ref double, out string);

int myfun(in string, inout double);

pragma(msg, typeof(__traits(getOverloads, forward!myfun, "myfun")[0]));
pragma(msg, typeof(__traits(getOverloads, forward!myfun, "myfun")[1]));

Output:
void(int, ref double, out string)
int(const(string), inout(double))

This deals with storage classes all right.

As for the string mixin, it would be nice to be able to do with it, or at least to narrow it to the function name, but in this respect D is more C than Lisp.