March 22
On Thursday, 21 March 2019 at 20:31:57 UTC, David Bennett wrote:
> On Sunday, 17 February 2019 at 21:04:23 UTC, Yuxuan Shui wrote:
>> After thinking about the feedback so far, I currently plan to make these changes to this DIP:
>>
>> ...
>
> Would you also be able to confirm how this DIP handles default arguments and templates?
> I think the DIP could use an example showing this off.

This DIP won't support template arguments.

And with my current plan this DIP probably won't help default arguments either.

>
> One of my almost dally 'is there no better way?' moments with D currently is default template arguments, for example to change throwErrors currently I need to do:
>
> ---
>
> T toString(T=string, bool SomeThing=true, bool throwErrors=true, S)(S value){return "";}
>
> auto foo = 123.toString!(string, true, false);
>
> ---
>
> Where as I think something like this would be better:
>
> ---
>
> auto foo = 123.toString!(throwErrors: false);
>
> ---

Yes, that would be better, but sadly that's out of the scope of this DIP.


March 22
On Monday, 4 March 2019 at 18:57:16 UTC, Olivier FAURE wrote:
> On Sunday, 3 March 2019 at 15:07:04 UTC, Joseph Rushton Wakeling wrote:
>> Well, since the current DIP is entirely opt-in from the function author side anyway, it's a bit of a moot point. I was responding rather to someone who was arguing that it should _not_ be opt in for function authors.
>
> My point was, the DIP should be opt-out, because even then library maintainers can always change argument names if they want to, without breaking code. And even if code does break, it's an extremely easy fix (as in, "change a few names until it compiles", not "refactor everything").
>
> Like, okay, I get that some people are opposed to the very idea of parameter names being important information to keep track of, but pragmatically, the costs of making named arguments the default are far outweighed by the benefits.

I agree that, having named arguments as the default would be better, _if_ we are designing a new language from ground up.

With D, even if we want to eventually make named arguments the default, it have to go through a deprecation path. IMHO, this is what a mature language should do.
March 22
On Friday, 22 March 2019 at 15:23:54 UTC, Yuxuan Shui wrote:
> I agree that, having named arguments as the default would be better, _if_ we are designing a new language from ground up.
>
> With D, even if we want to eventually make named arguments the default, it have to go through a deprecation path. IMHO, this is what a mature language should do.

Deprecation is typically used for changes to existing functionality that could break existing code. For example, the upcoming change to enable DIP 25 by default requires a deprecation process, because enabling DIP 25 will cause some code that currently works to fail to compile.

Named arguments, however, are a purely additive change to the language. They will not break any existing D code, because all existing D code uses positional arguments, and positional arguments will continue to work the same way they always have. Why, then, is a deprecation process necessary?
April 01
On Friday, 22 March 2019 at 15:18:09 UTC, Yuxuan Shui wrote:
> On Thursday, 21 March 2019 at 20:31:57 UTC, David Bennett wrote:
>> Would you also be able to confirm how this DIP handles default arguments and templates?
>> I think the DIP could use an example showing this off.
>
> This DIP won't support template arguments.
>
> And with my current plan this DIP probably won't help default arguments either.
>

That is unfortunate as its the part that gives me the most pain currently.

Almost so much as to make me feel like adding a 3rd named arguments DIP that only worked on default arguments.

Next ›   Last »
1 2 3 4 5 6 7 8 9 10 11