On 12/01/2019 12:24 AM, JN wrote:
> On Friday, 11 January 2019 at 07:53:56 UTC, rikki cattermole wrote:
>> On 11/01/2019 3:35 AM, JN wrote:
>>> Also, named/keyword arguments shouldn't be an issue in regards to overloading and argument order. Every language I know that has named/kw arguments allows either only keyword arguments or keywords arguments at the end of the argument list. You can do:
>>>
>>> foo(x=10)
>>> foo(10, 20, z=30)
>>>
>>> but you can't do:
>>>
>>> foo(x=10, 20)
>>>
>>> because it'd be ambiguous.
>>
>> Actually every example there is ambiguous and problematic in D.
>> It conflicts with AssignExpression which is identical in syntax and usage!
> 
> well, it's because I used the equality sign, languages like C# use :,
> 
> I guess:
> 
> foo(x:10, 20)
> 
> would be better?

Yup no ambiguity, that is why my named parameter DIP uses it :)

On Friday, 11 January 2019 at 11:25:39 UTC, rikki cattermole wrote:
> On 12/01/2019 12:24 AM, JN wrote:
>> On Friday, 11 January 2019 at 07:53:56 UTC, rikki cattermole wrote:
>>> On 11/01/2019 3:35 AM, JN wrote:
>>>> Also, named/keyword arguments shouldn't be an issue in regards to overloading and argument order. Every language I know that has named/kw arguments allows either only keyword arguments or keywords arguments at the end of the argument list. You can do:
>>>>
>>>> foo(x=10)
>>>> foo(10, 20, z=30)
>>>>
>>>> but you can't do:
>>>>
>>>> foo(x=10, 20)
>>>>
>>>> because it'd be ambiguous.
>>>
>>> Actually every example there is ambiguous and problematic in D.
>>> It conflicts with AssignExpression which is identical in syntax and usage!
>> 
>> well, it's because I used the equality sign, languages like C# use :,
>> 
>> I guess:
>> 
>> foo(x:10, 20)
>> 
>> would be better?
>
> Yup no ambiguity, that is why my named parameter DIP uses it :)

Is there even any usecase for AssignExpression within function parameters list? I imagine if (ptr = getPtr()) stuff can be useful (but still kind of risky if you actually intended ==), but putting assignments in function calls seems like could be disallowed without any negative effects.

On 12/01/2019 1:57 AM, JN wrote:
> On Friday, 11 January 2019 at 11:25:39 UTC, rikki cattermole wrote:
>> On 12/01/2019 12:24 AM, JN wrote:
>>> On Friday, 11 January 2019 at 07:53:56 UTC, rikki cattermole wrote:
>>>> On 11/01/2019 3:35 AM, JN wrote:
>>>>> Also, named/keyword arguments shouldn't be an issue in regards to overloading and argument order. Every language I know that has named/kw arguments allows either only keyword arguments or keywords arguments at the end of the argument list. You can do:
>>>>>
>>>>> foo(x=10)
>>>>> foo(10, 20, z=30)
>>>>>
>>>>> but you can't do:
>>>>>
>>>>> foo(x=10, 20)
>>>>>
>>>>> because it'd be ambiguous.
>>>>
>>>> Actually every example there is ambiguous and problematic in D.
>>>> It conflicts with AssignExpression which is identical in syntax and usage!
>>>
>>> well, it's because I used the equality sign, languages like C# use :,
>>>
>>> I guess:
>>>
>>> foo(x:10, 20)
>>>
>>> would be better?
>>
>> Yup no ambiguity, that is why my named parameter DIP uses it :)
> 
> Is there even any usecase for AssignExpression within function parameters list? I imagine if (ptr = getPtr()) stuff can be useful (but still kind of risky if you actually intended ==), but putting assignments in function calls seems like could be disallowed without any negative effects.

Our grammar looks very similar to C's in this area.
In both languages there are no assignment statements, only assignment expressions with expressions promoted to statements directly.

While we can make using AssignExpression like this illegal, it does make transition and porting to D harder from C. Perhaps Walter might be open to this? But personally while I might hate it, I don't think that it would be a good idea to remove it then use the same syntax for something else.

So use case? C does it like this. That should be enough to keep it as is sadly.

On 2019-01-10 15:00, Atila Neves wrote:


> Currently I'm trying to work out an efficient way to interpret D to run unit tests so I don't have to pay the linker tax and just avoid compiling code whilst developing.

LDC supports JIT.

-- 
/Jacob Carlborg

On Sunday, 13 January 2019 at 20:59:42 UTC, Jacob Carlborg wrote:
> On 2019-01-10 15:00, Atila Neves wrote:
>
>
>> Currently I'm trying to work out an efficient way to interpret D to run unit tests so I don't have to pay the linker tax and just avoid compiling code whilst developing.
>
> LDC supports JIT.

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.

The main problem is that I don't really know, and can't unless I measure. Which means implementing it somehow. Sigh.

On Thursday, 10 January 2019 at 18:27:59 UTC, Atila Neves wrote:
>> Look at the Builder pattern, it's pretty much a workaround for lack of named/keyword arguments.
>
> Java doesn't have variadic templates, D does. No builder pattern needed.

Not sure how variadic templates solves the builder pattern? How do you deal with a mixture of arguments of similar and different types with some being optional and not?

auto a = Builder()
  .accountNumber(202)
  .firstName("Bob")
  .lastName("Who")
  .branch("N-2")
  .interest(20.0)
  .balance(10.0)
  .build()

??

>
>> Also, named/keyword arguments shouldn't be an issue in regards to overloading and argument order. Every language I know that has named/kw arguments allows either only keyword arguments or keywords arguments at the end of the argument list. You can do:
>>
>> foo(x=10)
>> foo(10, 20, z=30)
>>
>> but you can't do:
>>
>> foo(x=10, 20)
>>
>> because it'd be ambiguous.
>
> I don't know of any language that does that and has overloading. Walter knows way more about this than I do.

Swift. Named arguments. Overloading. Executed perfectly IMO:

For the case mentioned above:

func f(x: Int, _ y: Int) {}

func main() {
    f(x: 10, 20)
}

Unless he means specifically with using named arguments with any order. Then yeah nah. Swift no can do. But named arguments followed by unnamed and vice versa plus overloading all good.

On Monday, 14 January 2019 at 14:31:09 UTC, aliak wrote:
> On Thursday, 10 January 2019 at 18:27:59 UTC, Atila Neves wrote:
>>> Look at the Builder pattern, it's pretty much a workaround for lack of named/keyword arguments.
>>
>> Java doesn't have variadic templates, D does. No builder pattern needed.
>
> Not sure how variadic templates solves the builder pattern? How do you deal with a mixture of arguments of similar and different types with some being optional and not?
>
> 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.
    }
}

If staticIndexOf is negative, assign a default value.


Again, I want to write a library that does this for me based on a declaration that looks like a regular function / template.

>> I don't know of any language that does that and has overloading. Walter knows way more about this than I do.
>
> Swift. Named arguments. Overloading. Executed perfectly IMO:

I can't comment. I don't know anything about Swift.

> Unless he means specifically with using named arguments with any order. Then yeah nah. Swift no can do. But named arguments followed by unnamed and vice versa plus overloading all good.

Probably? I don't really know.

On Monday, 14 January 2019 at 16:04:26 UTC, Atila Neves wrote:
>> Swift. Named arguments. Overloading. Executed perfectly IMO:
>
> I can't comment. I don't know anything about Swift.
What about C# then?
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments

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.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg