December 19, 2018
On Wednesday, 19 December 2018 at 13:30:57 UTC, Kagamin wrote:
> https://blog.jetbrains.com/dotnet/2018/11/27/inline-parameter-name-hints-c-vb-net-resharper-rider/ resharper 2018 just overlays parameter names right in editor window.

I think there are two usecases that are kind of getting mixed here, correct me if I'm wrong. Named/keyword arguments provide two benefits:

1) you know what the arguments mean at the call place
2) you can make optional arguments without making multiple function overloads or using something like the Builder pattern

This fixes 1) but doesn't fix 2)
December 19, 2018
On Tuesday, 18 December 2018 at 18:23:20 UTC, aliak wrote:
> Woah... that's quite neat.
>
> I feel like this is how std.typecons.Flag should have been made!!
>
> I played around with it for a bit, and if there was a way to get some better error messages then that could be quite nice to use! - i dunno, maybe through some static assert on the "string names"s being passed in or something...

Thanks, but it has some serious drawbacks - like this:

void fun(Args!byte.foo foo) {}

unittest {
    fun(args.foo = 3); // function foo.fun(Arg!("foo", byte) foo) is not callable using argument types (Arg!("foo", int))
}

For a limited use case like std.typecons.Flag, it could work pretty well, though:

struct Flag {
    alias opDispatch(string name) = FlagImpl!name;
}

template FlagImpl(string name) {
    // mixin to embetter type name.
    mixin(`struct `~name~` {
        bool value;
        alias value this;

        static typeof(this) opAssign(bool value) {
            return typeof(this)(value);
        }
    }`);
    mixin("alias FlagImpl = "~name~";");
}

void fun(Flag.exclusive exclusive) {
    assert(exclusive);
}

unittest {
    fun(Flag.exclusive = true);
}

--
  Simen
December 19, 2018
On Wed, 19 Dec 2018 15:07:48 +0000, JN wrote:
> On Wednesday, 19 December 2018 at 13:30:57 UTC, Kagamin wrote:
>> https://blog.jetbrains.com/dotnet/2018/11/27/inline-parameter-name-
hints-c-vb-net-resharper-rider/
>> resharper 2018 just overlays parameter names right in editor window.
> 
> I think there are two usecases that are kind of getting mixed here, correct me if I'm wrong. Named/keyword arguments provide two benefits:
> 
> 1) you know what the arguments mean at the call place
> 2) you can make optional arguments without making multiple function
> overloads or using something like the Builder pattern
> 
> This fixes 1) but doesn't fix 2)

D has optional arguments already, but the thing that reorderable named arguments can easily get you is not having to specify optional arguments 0 through n-1 just to specify optional argument n.
1 2 3
Next ›   Last »