February 10, 2020
On 2/10/2020 3:20 PM, Jonathan Marler wrote:
>   I took a quick look at std.math in phobos to see what some of the current argument names are:
> 
> auto conj(Num)(Num z) @safe pure nothrow @nogc
> auto abs(Num)(Num x) @nogc pure nothrow
> real cos(real x) @safe pure nothrow @nogc { pragma(inline, true); return core.math.cos(x); }
> auto sin(creal z) @safe pure nothrow @nogc
> auto sin(ireal y) @safe pure nothrow @nogc
> 
> So we have some of this:
> 
> conj(z:someValue);
> abs(x:someValue);
> sin(y:someValue);
> 
> Now that parameter names are apart of the function's API, this inconsistency starts to matter

It isn't inconsistent. In math, z=x+iy is normal notation, i.e. x for real numbers, y for imaginary, and z for complex.

Besides, I doubt there's much of any point for using named parameters for those functions.
February 10, 2020
On Mon, Feb 10, 2020 at 4:45 PM Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 11 February 2020 at 00:03:01 UTC, aliak wrote:
> > I do agree that having something like ParametersWithNamesAndDefaultArgs is infeasible.
>
> I posted this earlier in this very thread:
>
> https://forum.dlang.org/post/cfcgecteoeynumsamjwe@forum.dlang.org
>
> It is not only feasible... but trivial. ParametersWithNamesAndDefaultArgs is a *built-in language feature* - see 5.6 under here https://dlang.org/spec/expression.html#IsExpression
>
> Forwarding this stuff is not difficult at all.

Sorry, I missed that above. Thanks for pointing this out.
I did not realise __parameters populated the tuple with all that
information... it's not even clear to me how that works!

What manner of 'thing' exists in a tuple that can be a type, but also
have a name and a default value associated with it?
Whatever kind of thing the elements in the tuple are; this seems very
useful, and I wanna know how to deploy this kind of thing generally.
I don't even know what to call this... it's not a 'type' or a 'value',
what 'kind of thing' is this?
I guess it's a declaration alias. I wonder how this syntax is useful
elsewhere...
February 10, 2020
On 2/10/2020 10:39 AM, Steven Schveighoffer wrote:
> [...]
Thanks, you said it better than I!
February 11, 2020
On 09.02.20 03:31, Adam D. Ruppe wrote:
> On Sunday, 9 February 2020 at 02:15:36 UTC, Jon Degenhardt wrote:
>> Or perhaps a way to discourage it, for example, a compile-time warning about no-backward compatibility for parameter names.
> 
> I would kinda love user-defined warnings. pragma(msg) comes close sometimes but there is no way to conditionally trigger it. (You can sort of conditionally disable via `version()` though.)
> 
> Of course, you could just name your parameters `_randomNameYouReallyDontWantToUse_like_seriously_dont_rely_on_this_name_lol` :P

int justDoThis(int,int){
    return _param_0+_param_1;
}
February 11, 2020
On 09.02.20 21:59, Walter Bright wrote:
> On 2/9/2020 11:51 AM, Arine wrote:
>> struct A {
>>     int foo;
>> }
>>
>> struct A {
>>      int bar; // renamed from foo
>>      deprecated alias foo = bar;
>> };
>>
>>
>> False equivalency, you have many tools at your disposal to deal with this for structs.
> 
> 
> C has it, too. Never heard a single complaint about it, either.
> 
> https://en.cppreference.com/w/c/language/struct_initialization

If you change the name of a field, code that accesses the field in the standard way also breaks. It would be rather weird if people complained specifically about broken initializers.
February 11, 2020
On 10.02.20 20:46, Adam D. Ruppe wrote:
> On Monday, 10 February 2020 at 19:38:34 UTC, Manu wrote:
>> If we must mirror
>> the argument names and default arguments, you must fall back into string mixin territory
> 
> It is super simple. Consider this example:
> 
> ---
> int foo(string s = null, int a = 12) {
>          return a + 12;
> }
> template wrapWithPrint(alias fn) {
>          static if(is(typeof(fn) P == __parameters))
>          auto wrapWithPrint(P params) {
>                  import std.stdio;
>                  writeln(params);
>                  auto ret = fn(params);
>                  writeln("returned: ", ret);
>                  return ret;
>          }
>          else static assert(0);
> }
> void main() {
>          wrapWithPrint!foo();
>          wrapWithPrint!foo("cool");
>          wrapWithPrint!foo("cool", 20);
> }
> ---
> 
> Default values and param names are included in the __parameters thing and just works if you use it directly.
> 
> I saw people overcomplicating this just a few hours ago too which is why I have this example ready. There's plenty of techniques to do this though I guess they aren't well known.

What if fn is a template?
February 11, 2020
On Monday, 10 February 2020 at 21:29:41 UTC, 12345swordy wrote:

> Yes, I have encounter the "API breakage" counter argument in other threads already. Still not convinced that it is a big issue as they make it out to be.

I don't know since when you are around in D-land, but I'm here since pre-1.0. Not ad hominem, but believe me, I think it's difficult to understand the immane efforts to convince the leadership that breakage for a solid reason is not an evil thing.

The pendulum is waving between "breakage is not even taken in account" to "let's introduce more ways to have MORE breakage opportunity in the future".

Maybe it's not a "bit issue" for someone, Walter included, but that's non sense, plain and simple.

Until I will see a shift from 'virtual by default' to 'final by default' mentality, aka let's try to reduce FUTURE opportunity for breakage, I will push toward that direction.

/P
February 11, 2020
On Monday, 10 February 2020 at 22:20:21 UTC, Adam D. Ruppe wrote:

> In D, this is the most trivial type of breakage - the compiler tells you where the change is and can make a good guess as to what the fix is too and can suggest it.
>


That's true, but it's an hell when involving libraries: an external library author changes a parameter names, and break not only your codebase, that you can easily fix, but also other external libraries, and so on.

It's a cascade process.


February 11, 2020
On Tuesday, 11 February 2020 at 09:18:38 UTC, Paolo Invernizzi wrote:
> On Monday, 10 February 2020 at 22:20:21 UTC, Adam D. Ruppe wrote:
>
>> In D, this is the most trivial type of breakage - the compiler tells you where the change is and can make a good guess as to what the fix is too and can suggest it.
>>
>
>
> That's true, but it's an hell when involving libraries: an external library author changes a parameter names, and break not only your codebase, that you can easily fix, but also other external libraries, and so on.
>
> It's a cascade process.

If package dependencies are used correctly nothing is break :)

Andrea
February 11, 2020
On 10.02.20 20:46, Adam D. Ruppe wrote:
> 
> It is super simple. Consider this example:
> 
> ---
> template wrapWithPrint(alias fn) {
>          static if(is(typeof(fn) P == __parameters))
>          auto wrapWithPrint(P params) {
>                  import std.stdio;
>                  writeln(params);
>                  auto ret = fn(params);
>                  writeln("returned: ", ret);
>                  return ret;
>          }
>          else static assert(0);
> }
> ---

int troll(int ret){ return ret; }

void main(){
    wrapWithPrint!troll(2);
}