On Friday, 14 December 2018 at 20:13:42 UTC, bauss wrote:
> In C++ you can achieve named arguments using templates and operator overload:
>
> It's sad that D is still against having named arguments, but it's possible in something that D thrives to be better than.
>
> https://www.fluentcpp.com/2018/12/14/named-arguments-cpp/
>
> I assume this is not possible to port to D because D doesn't do operator overload in the same way C++ does, correct?
>
> I still think named arguments should be something to consider implementing for D, but since everything requires a DIP and it's very hard to write a DIP that's proper for such a thing then I guess it'll just be a dream, forever.

I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.

On Sunday, 16 December 2018 at 22:16:28 UTC, Matthew OConnor wrote:
> I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.

Sweet zombie Jesus I just read the article and wow I can't believe that was written _this week_. Named arguments by defining non-thread-safe statics? People write this tripe in 2018? And get _good comments_ on it?

Something has gone very wrong in compsci education.

On Sunday, 16 December 2018 at 22:16:28 UTC, Matthew OConnor wrote:
>
> I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.

Well that's the problem. If it was implemented as a language feature it'd be a clean solution with nice syntax. But trying to force it with templates will always look ugly.

On Monday, 17 December 2018 at 21:11:03 UTC, JN wrote:
> On Sunday, 16 December 2018 at 22:16:28 UTC, Matthew OConnor wrote:
>>
>> I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.
>
> Well that's the problem. If it was implemented as a language feature it'd be a clean solution with nice syntax. But trying to force it with templates will always look ugly.

IMHO, there's no point, just wrap every parameter in a struct. Is there really that much of a difference between:

displayCoolName(firstName = "James", lastName = "Bond")

and

displayCoolName(FirstName("James"), LastName("Bond"))

?

It's not even fewer characters! It's not trivial but it's possible to make the order not matter by using a templated implementation and aliasing it to `displayCoolName`.

On Monday, 17 December 2018 at 19:24:06 UTC, Ethan wrote:
> On Sunday, 16 December 2018 at 22:16:28 UTC, Matthew OConnor wrote:
>> I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.
>
> Sweet zombie Jesus I just read the article and wow I can't believe that was written _this week_. Named arguments by defining non-thread-safe statics? People write this tripe in 2018? And get _good comments_ on it?
>
> Something has gone very wrong in compsci education.

At least the static variables are const...

On Tuesday, 18 December 2018 at 10:44:28 UTC, Atila Neves wrote:
>
> IMHO, there's no point, just wrap every parameter in a struct. Is there really that much of a difference between:
>
> displayCoolName(firstName = "James", lastName = "Bond")
>
> and
>
> displayCoolName(FirstName("James"), LastName("Bond"))
>
> ?
>
> It's not even fewer characters! It's not trivial but it's possible to make the order not matter by using a templated implementation and aliasing it to `displayCoolName`.

Well, but then you have to create structs for everything you want to pass to the method. And you have to explicitly define which arguments can be passed by name. In languages like C#, you don't have to mark arguments as named or anything like that, you just pass the names at the call site.

On Tuesday, 18 December 2018 at 10:44:28 UTC, Atila Neves wrote:
> On Monday, 17 December 2018 at 21:11:03 UTC, JN wrote:
>> On Sunday, 16 December 2018 at 22:16:28 UTC, Matthew OConnor wrote:
>>>
>>> I am a C++ developer by day and reading that article made me cringe. C++ has this creeping, expansive, everything ends up in the language or writable in it, if you accept awful messages and contorting the syntax. I hope D doesn't go down that route.
>>
>> Well that's the problem. If it was implemented as a language feature it'd be a clean solution with nice syntax. But trying to force it with templates will always look ugly.
>
> IMHO, there's no point, just wrap every parameter in a struct. Is there really that much of a difference between:
>
> displayCoolName(firstName = "James", lastName = "Bond")
>
> and
>
> displayCoolName(FirstName("James"), LastName("Bond"))
>
> ?
>
> It's not even fewer characters! It's not trivial but it's possible to make the order not matter by using a templated implementation and aliasing it to `displayCoolName`.

You also have to build it:

func toHex(r: Int, g: Int, b: Int) -> Int {
  return r << g << b;
}

As opposed to:

struct R {
  int value;
}
struct G {
  int value;
}
struct B {
  int value;
}
int toHex(R r, G g, B b) {
  return r.value << g.value << b.value;
}

That's 67 vs 146 characters. Not to mention one pollutes the namespace and one doesn't.

On Tuesday, 18 December 2018 at 11:08:43 UTC, aliak wrote:
>> It's not even fewer characters! It's not trivial but it's possible to make the order not matter by using a templated implementation and aliasing it to `displayCoolName`.
>
> You also have to build it:
>
> func toHex(r: Int, g: Int, b: Int) -> Int {
>   return r << g << b;
> }
>
> As opposed to:
>
> struct R {
>   int value;
> }
> struct G {
>   int value;
> }
> struct B {
>   int value;
> }
> int toHex(R r, G g, B b) {
>   return r.value << g.value << b.value;
> }
>
> That's 67 vs 146 characters. Not to mention one pollutes the namespace and one doesn't.

No need to pollute the namespace:

struct args {
    template opDispatch(string name) {
        alias opDispatch = Arg!name;
    }
}

struct Args(T) {
    template opDispatch(string name) {
        alias opDispatch = Arg!(name, T);
    }
}

struct Arg(string name) {
    static auto opAssign(T)(T value) {
        return Arg!(name, T)(value);
    }
}

struct Arg(string name, T) {
    T value;
    alias value this;
}

void fun(Args!int.foo foo) {} // Unfortunately requires repetition of arg name. :(

unittest {
    fun(args.foo = 3);
}

--
  Simen

On Tuesday, 18 December 2018 at 11:15:26 UTC, Simen Kjærås wrote:
> On Tuesday, 18 December 2018 at 11:08:43 UTC, aliak wrote:
>>> It's not even fewer characters! It's not trivial but it's possible to make the order not matter by using a templated implementation and aliasing it to `displayCoolName`.
>>
>> You also have to build it:
>>
>> func toHex(r: Int, g: Int, b: Int) -> Int {
>>   return r << g << b;
>> }
>>
>> As opposed to:
>>
>> struct R {
>>   int value;
>> }
>> struct G {
>>   int value;
>> }
>> struct B {
>>   int value;
>> }
>> int toHex(R r, G g, B b) {
>>   return r.value << g.value << b.value;
>> }
>>
>> That's 67 vs 146 characters. Not to mention one pollutes the namespace and one doesn't.
>
> No need to pollute the namespace:
>
> struct args {
>     template opDispatch(string name) {
>         alias opDispatch = Arg!name;
>     }
> }
>
> struct Args(T) {
>     template opDispatch(string name) {
>         alias opDispatch = Arg!(name, T);
>     }
> }
>
> struct Arg(string name) {
>     static auto opAssign(T)(T value) {
>         return Arg!(name, T)(value);
>     }
> }
>
> struct Arg(string name, T) {
>     T value;
>     alias value this;
> }
>
> void fun(Args!int.foo foo) {} // Unfortunately requires repetition of arg name. :(
>
> unittest {
>     fun(args.foo = 3);
> }
>
> --
>   Simen

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...

Cheers,
- Ali

On Friday, 14 December 2018 at 20:13:42 UTC, bauss wrote:
> In C++ you can achieve named arguments using templates and operator overload:
>
> It's sad that D is still against having named arguments, but it's possible in something that D thrives to be better than.
>
> https://www.fluentcpp.com/2018/12/14/named-arguments-cpp/

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.