Re: What Mike thinks
On Thursday, 17 September 2020 at 20:13:23 UTC, Cym13 wrote: On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote: What Mike thinks appears nowhere in my post :-) That's a bit sad. I understand that in your position it may be hard to express a personnal opinion but I think anyone should get the opportunity to do so. Would you like, in no official capacity whatsoever, to provide your personnal take on the matter? I think you took that comment the wrong way :-) The announcement provides the rationale behind the decision Walter and Atila made. I just wanted to make it clear for anyone reading Jean-Louis's comment that I wasn't posting my opinion. For the record, I have no opinion on this DIP one way or another. Named arguments don't interest me at all. I think you should get to express your feelings as well :) But of course I would understand if you don't want to get involved in any particular issue. Given that I work closely with DIP authors to revise their DIPs, and that sometimes that involves more than just proofreading, I don't think it's appropriate for me to publicly take a position on any of them. I don't want any author to feel I have an ulterior motive in any content revision suggestions I make, and I don't want to color my own judgement.
Re: DIP 1030-- Named Arguments--Formal Assessment
On 9/17/2020 6:42 AM, Jean-Louis Leroy wrote: That being said, does the new feature imply any change in the *parameters* themselves? No. I.e. are there changes in the way the function is defined, No. not only in the way it is called? It only affects calling syntax in providing an alternative way to call a function.
Re: DIP 1030-- Named Arguments--Formal Assessment
On 9/17/20 8:58 AM, Mike Parker wrote: So they decided that a new `std.traits` template and a corresponding `__traits` option are needed which expand into the exact function signature of another function. This, sounds great. I'd love to see the specifics for this. Also, I am very much looking forward to named parameters! I hope call forwarding can be done in a simple a way as it's done now. -Steve
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: DIP 1030, "Named Arguments", has been accepted. During the assessment, Walter and Atila had a discussion regarding this particular criticism: [...] Calls for celebration... who's in?
What Mike thinks
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote: What Mike thinks appears nowhere in my post :-) That's a bit sad. I understand that in your position it may be hard to express a personnal opinion but I think anyone should get the opportunity to do so. Would you like, in no official capacity whatsoever, to provide your personnal take on the matter? I think you should get to express your feelings as well :) But of course I would understand if you don't want to get involved in any particular issue.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: DIP 1030, "Named Arguments", has been accepted. I would really want to see tuples ...
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote: On Thursday, 17 September 2020 at 13:42:47 UTC, Jean-Louis Leroy wrote: this point I have some hope that the DIP is not damaging in the way Mike thinks. What Mike thinks appears nowhere in my post :-) OK, s/thinks/reports/ ;-)
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 13:42:47 UTC, Jean-Louis Leroy wrote: this point I have some hope that the DIP is not damaging in the way Mike thinks. What Mike thinks appears nowhere in my post :-)
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 13:23:38 UTC, Jean-Louis Leroy wrote: Actually, Parameters!origFun will carry storage classes, UDAs, etc for all the parameters. And Parameters!origFun[0..1] (note the two dots) will carry everything about the first parameter. The trouble begins when, for some reason, you need to manipulate the parameter at a finer level. For example, in openmethods, I need to change the type while preserving everything else. (For the rest of this post, to make things clear, I will call Parameter declarations that appear inside the function definition, and Arguments the values that are passed to a function call). I like named arguments. However, I would be greatly disappointed if: 1/ Parameters!origFun and Parameters!origFun[i..i+1] stopped working as well as they do now. 2/ The named arguments did not come with new traits (or at least is(__parameter) magic) to allow fully analyzing the parameters. That being said, does the new feature imply any change in the *parameters* themselves? I.e. are there changes in the way the function is defined, not only in the way it is called? I have not followed the discussion and just skimmed over the DIP now. I'm going to try to find time for this. However, at this point I have some hope that the DIP is not damaging in the way Mike thinks.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
DIP 1030, "Named Arguments", has been accepted.
During the assessment, Walter and Atila had a discussion
regarding this particular criticism:
https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmar...@puremagic.com
"Named arguments breaks this very important pattern:
auto wrapper(alias origFun)(Parameters!origFun args)
{
// special sauce
return origFun(args);
}"
They say that, though it's true that `Parameters!func` will not
work in a wrapper, it "doesn't really work now"---default
arguments and storage classes must be accounted for. This can
be done with string mixins, or using a technique referred to by
Jean-Louis Leroy as "refraction", both of which are clumsy.
Actually, Parameters!origFun will carry storage classes, UDAs,
etc for all the parameters. And Parameters!origFun[0..1] (note
the two dots) will carry everything about the first parameter.
The trouble begins when, for some reason, you need to manipulate
the parameter at a finer level. For example, in openmethods, I
need to change the type while preserving everything else.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote: On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: DIP 1030, "Named Arguments", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md YES, YES, YES, I had argue in favor of this dip so hard in the past years. Thank you Walter. -Alex
DIP 1030-- Named Arguments--Formal Assessment
DIP 1030, "Named Arguments", has been accepted.
During the assessment, Walter and Atila had a discussion
regarding this particular criticism:
https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmar...@puremagic.com
"Named arguments breaks this very important pattern:
auto wrapper(alias origFun)(Parameters!origFun args)
{
// special sauce
return origFun(args);
}"
They say that, though it's true that `Parameters!func` will not
work in a wrapper, it "doesn't really work now"---default
arguments and storage classes must be accounted for. This can be
done with string mixins, or using a technique referred to by
Jean-Louis Leroy as "refraction", both of which are clumsy.
So they decided that a new `std.traits` template and a
corresponding `__traits` option are needed which expand into the
exact function signature of another function.
They also acknowledge that when an API's parameter names change,
code depending on the old parameter names will break. Struct
literals have the same problem and no one complains (the same is
true for C99). And in any case, when such a change occurs, it's a
hard failure as any code using named arguments with the old
parameter names will fail to compile, making it easy to see how
to resolve the issue. Given this, they find the benefits of the
feature outweigh the potential for such breakage.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: DIP 1030, "Named Arguments", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md
Re: Beta 2.094.0
On Wednesday, 16 September 2020 at 18:52:23 UTC, Jacob Carlborg wrote: On 2020-09-16 19:20, mw wrote: Why it's deprecated? can we revive it? It was deprecated because it's a bad idea to not lock versions. Using `~master` would fetch the latest code from the "master" branch when compiling. You never know which version you get. You don't get reproducible builds. I personally think it's not so bad as long as the commit gets written to the dub.selections.json
