On 1/14/19 3:05 PM, Jacob Carlborg wrote:
> On 2019-01-14 15:31, aliak wrote:
> 
>> Swift. Named arguments. Overloading. Executed perfectly IMO:
> 
> Technically it's not function overloading. The functions have separate names, the parameter keys are part of the name. That's at least how it works in Objective-C.
> 

I was going to say that, but I feel like possibliy in my dealings with Swift (which isn't huge), it may have had more abilities for overloading than objective-C.

-Steve

On Monday, 14 January 2019 at 20:59:11 UTC, Steven Schveighoffer wrote:
> On 1/14/19 3:05 PM, Jacob Carlborg wrote:
>> On 2019-01-14 15:31, aliak wrote:
>> 
>>> Swift. Named arguments. Overloading. Executed perfectly IMO:
>> 
>> Technically it's not function overloading. The functions have separate names, the parameter keys are part of the name. That's at least how it works in Objective-C.
>> 
>
> I was going to say that, but I feel like possibliy in my dealings with Swift (which isn't huge), it may have had more abilities for overloading than objective-C.
>
> -Steve

You can use the same keys with different types and call the correct function based on argument type. You can even overload based on return type alone!

I don't remember if that was possible in objective-c or not - flushed from me system :p

On Monday, 14 January 2019 at 20:02:55 UTC, Jacob Carlborg wrote:
> On 2019-01-14 14:54, Atila Neves wrote:
>
>> I don't think that'd be useful for me. The only thing I care about is the latency between hitting a key and having feedback on my tests. It's rare that I have tests that would be significantly faster by optimising the machine code running on the CPU.
>
> I didn't mean to use a JIT to optimize the execution. I was more thinking of using LDC as a JIT to avoid having to implement your own interpreter. But the JIT might be too slow to compile the code.
>
> Hmm, can use use the CTFE interpreter in DMD? Hack that to use it for none CTFE stuff as well.

I tried that first - many of the declarations are private and it was a pain to reuse the code. Then I started writing an interpreter from scratch and realised very soon how much work that would be.

I need to try and reuse the existing code again. I'm also not sure how to deal with imported code from dependencies yet and am a bit in analysis paralysis.

On Monday, 14 January 2019 at 16:04:26 UTC, Atila Neves wrote:
> On Monday, 14 January 2019 at 14:31:09 UTC, aliak wrote:
>> auto a = Builder()
>>   .accountNumber(202)
>>   .firstName("Bob")
>>   .lastName("Who")
>>   .branch("N-2")
>>   .interest(20.0)
>>   .balance(10.0)
>>   .build()
>>
>> ??
>
> auto a = Customer(AccountNumber(202),
>                   FirstName("Bob"),
>                   LastName("Who"),
>                   Branch("N-2"),
>                   Interest(20.0),
>                   Balance(10.0));
>
> struct Customer {
>     this(A...)(auto ref A args) if(constraintVerifyingNumberAndTypesOfArgs!A) {
>         this.accountNumber = args[staticIndexOf!(AccountNumber, A)];
>         // etc.
>     }
> }

I think these design patterns are useful if you really want named arguments in your code right now, but they really shouldn't replace the structure initialization DIP.

Personally speaking, I hate having hacks like these in my code and would immensely prefer an idiomatic syntax eg:

    auto a = Customer{ accountNumber: 202, fistName: "Bob" };

which would produce easy-to-read error messages like:

    Error: `fistName` is not a member of `Customer`. Did you mean `firstName`?

    Error: Initialization list for `Customer` does not provide value for member variable `lastName`, which has no default value defined.

I'm having trouble guessing what error messages your Customer structure would provide, but I imagine they wouldn't be nearly as informative. Same thing for generated documentation.

On Tuesday, 15 January 2019 at 12:42:32 UTC, Olivier FAURE wrote:
> On Monday, 14 January 2019 at 16:04:26 UTC, Atila Neves wrote:
>> [...]
>
> I think these design patterns are useful if you really want named arguments in your code right now, but they really shouldn't replace the structure initialization DIP.
>
> [...]

Good error messages are perfectly doable with a library solution. Sure, the "Did you mean" one is harder to implement, but still doable.