www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP88 Named Parameters, Status?

reply Jonathan Marler <johnnymarler gmail.com> writes:
https://wiki.dlang.org/DIP88

I'd like to see DIP88 (Named Parameters) revived.  Was this 
proposal rejected or is it just stale and needs a refresh?  Named 
parameters can be implemented in a library, however, in my 
opinion they are useful enough to warrant a clean syntax with 
language support.  I'd be willing to refresh the DIP so long as I 
know the idea has not already been rejected.
Sep 30 2017
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 30, 2017 16:10:44 Jonathan Marler via Digitalmars-d 
wrote:

 https://wiki.dlang.org/DIP88

 I'd like to see DIP88 (Named Parameters) revived.  Was this
 proposal rejected or is it just stale and needs a refresh?  Named
 parameters can be implemented in a library, however, in my
 opinion they are useful enough to warrant a clean syntax with
 language support.  I'd be willing to refresh the DIP so long as I
 know the idea has not already been rejected.


Effectively, all DIPs from that wiki that have not already been accepted are
dead, regardless of whether they stand any chance of acceptance. For any DIP
to be accepted, it will have to go through the new DIP process, which
essentially means creating a new DIP.

As for named parameters specifically, I'd be very surprised to see them
added to the language. From what I recall, Walter wasn't particularly fond
of the idea, and since it _is_ possible to implement them with a library
solution, it's exactly the sort of thing that Andrei is likely to veto. At
this point, in general, if something can be done in the language as it
stands, it's not likely for it to be accepted as a DIP. Now, that's dealt
with on a case by case basis, so I can't say for certain that a DIP for
named parameters would be rejected, but I would expect it to be.

- Jonathan M Davis
Sep 30 2017
parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis 
wrote:

 Effectively, all DIPs from that wiki that have not already been 
 accepted are dead, regardless of whether they stand any chance 
 of acceptance. For any DIP to be accepted, it will have to go 
 through the new DIP process, which essentially means creating a 
 new DIP.

 As for named parameters specifically, I'd be very surprised to 
 see them added to the language. From what I recall, Walter 
 wasn't particularly fond of the idea, and since it _is_ 
 possible to implement them with a library solution, it's 
 exactly the sort of thing that Andrei is likely to veto. At 
 this point, in general, if something can be done in the 
 language as it stands, it's not likely for it to be accepted as 
 a DIP. Now, that's dealt with on a case by case basis, so I 
 can't say for certain that a DIP for named parameters would be 
 rejected, but I would expect it to be.

 - Jonathan M Davis


What about DIP45, or making export an attribute? That would help 
the language to go mainstream.
Sep 30 2017
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 30, 2017 16:57:09 solidstate1991 via Digitalmars-d 
wrote:

 On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis

 wrote:

 Effectively, all DIPs from that wiki that have not already been
 accepted are dead, regardless of whether they stand any chance
 of acceptance. For any DIP to be accepted, it will have to go
 through the new DIP process, which essentially means creating a
 new DIP.

 As for named parameters specifically, I'd be very surprised to
 see them added to the language. From what I recall, Walter
 wasn't particularly fond of the idea, and since it _is_
 possible to implement them with a library solution, it's
 exactly the sort of thing that Andrei is likely to veto. At
 this point, in general, if something can be done in the
 language as it stands, it's not likely for it to be accepted as
 a DIP. Now, that's dealt with on a case by case basis, so I
 can't say for certain that a DIP for named parameters would be
 rejected, but I would expect it to be.

 - Jonathan M Davis


 What about DIP45, or making export an attribute? That would help
 the language to go mainstream.


As I said, any DIPs on the wiki which have not already been accepted are
effectively dead, because the wiki is no longer part of the official DIP
process (not that there was much of a process before, which was part of the
problem). Whether any of the DIPs on the wiki are a good idea or not is
irrelevant. Any DIP that's going to be accepted needs to go through the
current DIP process:

https://github.com/dlang/DIPs

No DIPs are going to magically move from the wiki to github. _Someone_ (be
it the original DIP author or someone else) is going to have to take the
time and make the effort to do everything that's required as part of the
current DIP process, or the DIP will never go anywhere.

- Jonathan M Davis
Sep 30 2017
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 30 September 2017 at 22:37:31 UTC, Jonathan M Davis 
wrote:

 On Saturday, September 30, 2017 16:57:09 solidstate1991 via 
 Digitalmars-d wrote:

 On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M 
 Davis

 wrote:

 [...]


 What about DIP45, or making export an attribute? That would 
 help the language to go mainstream.


 As I said, any DIPs on the wiki which have not already been 
 accepted are effectively dead, because the wiki is no longer 
 part of the official DIP process (not that there was much of a 
 process before, which was part of the problem). Whether any of 
 the DIPs on the wiki are a good idea or not is irrelevant. Any 
 DIP that's going to be accepted needs to go through the current 
 DIP process:

 https://github.com/dlang/DIPs

 No DIPs are going to magically move from the wiki to github. 
 _Someone_ (be it the original DIP author or someone else) is 
 going to have to take the time and make the effort to do 
 everything that's required as part of the current DIP process, 
 or the DIP will never go anywhere.

 - Jonathan M Davis


Hoping that someone will chime in and answer the original 
question.  It's likely that only Walter or Andrei can answer it.

Is it a waste of time for me to put effort into renewing this 
DIP?  Is it dead on arrival or is there a chance it could be 
accepted?
Sep 30 2017
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 01, 2017 01:54:24 Jonathan Marler via Digitalmars-d 
wrote:

 Hoping that someone will chime in and answer the original
 question.  It's likely that only Walter or Andrei can answer it.

 Is it a waste of time for me to put effort into renewing this
 DIP?  Is it dead on arrival or is there a chance it could be
 accepted?


Literally, only Walter and Andrei could answer that, because they're the
only ones making the decision. Based on what they've said in the past, I
would not expect it to be accepted, but it's up to them, and the most that
any of the rest of us can do is speculate based on what Walter and Andrei
have stated in the past. At bare minimum, I can guarantee that you would
have to come up with a very compelling argument as to why a library solution
really doesn't cut it, because their answer is almost always no when a
library solution can solve the problem - and there are plenty of cases where
someone has tried to argue that something should be done in the language
because it's less ugly that way, and that rarely seems to get anyone very
far.

In any case, historically around here, folks asking whether it's worth their
time to do something before they do it really don't get a yes or no. The
only way to know for sure is to do it.

- Jonathan M Davis
Sep 30 2017
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 1 October 2017 at 01:54:24 UTC, Jonathan Marler wrote:

 On Saturday, 30 September 2017 at 22:37:31 UTC, Jonathan M 
 Davis wrote:

 On Saturday, September 30, 2017 16:57:09 solidstate1991 via 
 Digitalmars-d wrote:

 On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M 
 Davis

 wrote:

 [...]


 What about DIP45, or making export an attribute? That would 
 help the language to go mainstream.


 As I said, any DIPs on the wiki which have not already been 
 accepted are effectively dead, because the wiki is no longer 
 part of the official DIP process (not that there was much of a 
 process before, which was part of the problem). Whether any of 
 the DIPs on the wiki are a good idea or not is irrelevant. Any 
 DIP that's going to be accepted needs to go through the 
 current DIP process:

 https://github.com/dlang/DIPs

 No DIPs are going to magically move from the wiki to github. 
 _Someone_ (be it the original DIP author or someone else) is 
 going to have to take the time and make the effort to do 
 everything that's required as part of the current DIP process, 
 or the DIP will never go anywhere.

 - Jonathan M Davis


 Hoping that someone will chime in and answer the original 
 question.  It's likely that only Walter or Andrei can answer it.

 Is it a waste of time for me to put effort into renewing this 
 DIP?  Is it dead on arrival or is there a chance it could be 
 accepted?


If you're talking about DIP45, I think it has a good chance of 
being accepted, as Walter had positive feedback after Benjamin's 
talk (https://dconf.org/2016/talks/thaut.html around 38:00 on the 
video):

Walter (to Benjamin): You and I have argued about that export 
thing before and I think you've made pretty compelling case for 
it. You know what you're doing, so move forward with it and get 
it done.
Oct 01 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/01/2017 06:51 AM, Petar Kirov [ZombineDev] wrote:

 On Sunday, 1 October 2017 at 01:54:24 UTC, Jonathan Marler wrote:

 On Saturday, 30 September 2017 at 22:37:31 UTC, Jonathan M Davis wrote:

 On Saturday, September 30, 2017 16:57:09 solidstate1991 via 
 Digitalmars-d wrote:

 On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M Davis

 wrote:

 [...]


 What about DIP45, or making export an attribute? That would help the 
 language to go mainstream.


 As I said, any DIPs on the wiki which have not already been accepted 
 are effectively dead, because the wiki is no longer part of the 
 official DIP process (not that there was much of a process before, 
 which was part of the problem). Whether any of the DIPs on the wiki 
 are a good idea or not is irrelevant. Any DIP that's going to be 
 accepted needs to go through the current DIP process:

 https://github.com/dlang/DIPs

 No DIPs are going to magically move from the wiki to github. 
 _Someone_ (be it the original DIP author or someone else) is going to 
 have to take the time and make the effort to do everything that's 
 required as part of the current DIP process, or the DIP will never go 
 anywhere.

 - Jonathan M Davis


 Hoping that someone will chime in and answer the original question.  
 It's likely that only Walter or Andrei can answer it.

 Is it a waste of time for me to put effort into renewing this DIP?  Is 
 it dead on arrival or is there a chance it could be accepted?


 
 If you're talking about DIP45, I think it has a good chance of being 
 accepted, as Walter had positive feedback after Benjamin's talk 
 (https://dconf.org/2016/talks/thaut.html around 38:00 on the video):
 
 Walter (to Benjamin): You and I have argued about that export thing 
 before and I think you've made pretty compelling case for it. You know 
 what you're doing, so move forward with it and get it done.


Yes, we're up for that. We need a strong folow-up here (in the form of a 
formal proposal) from Benjamin and others interested. -- Andrei
Oct 14 2017
parent solidstate1991 <laszloszeremi outlook.com> writes:
On Saturday, 14 October 2017 at 14:49:27 UTC, Andrei Alexandrescu 
wrote:

 Yes, we're up for that. We need a strong folow-up here (in the 
 form of a formal proposal) from Benjamin and others interested. 
 -- Andrei


I myself might try to resurrect the issue (probably in the 
forum), as a better DLL support under Windows would help D to 
move forward. Windows is the most used platform, and a better DLL 
support would open the door for a lot of opportunities (easier 
use of D for low-level scripting, interfacing with other 
software, etc.). D has the power to replace C++, but only if it 
takes the right directions.
Oct 15 2017
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 30 September 2017 at 16:57:09 UTC, solidstate1991 
wrote:

 On Saturday, 30 September 2017 at 16:22:37 UTC, Jonathan M 
 Davis wrote:

 Effectively, all DIPs from that wiki that have not already 
 been accepted are dead, regardless of whether they stand any 
 chance of acceptance. For any DIP to be accepted, it will have 
 to go through the new DIP process, which essentially means 
 creating a new DIP.

 As for named parameters specifically, I'd be very surprised to 
 see them added to the language. From what I recall, Walter 
 wasn't particularly fond of the idea, and since it _is_ 
 possible to implement them with a library solution, it's 
 exactly the sort of thing that Andrei is likely to veto. At 
 this point, in general, if something can be done in the 
 language as it stands, it's not likely for it to be accepted 
 as a DIP. Now, that's dealt with on a case by case basis, so I 
 can't say for certain that a DIP for named parameters would be 
 rejected, but I would expect it to be.

 - Jonathan M Davis


 What about DIP45, or making export an attribute? That would 
 help the language to go mainstream.


I was going to do this as part of DIP1012 but Martin Nowak 
advised me that I should remove it because DIP45 was still being 
worked on by Benjamin Thaut and that it had some advantages over 
doing what C/C++ does. So I removed it from DIP1012.
Sep 30 2017
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler 
wrote:

 https://wiki.dlang.org/DIP88

 I'd like to see DIP88 (Named Parameters) revived.  Was this 
 proposal rejected or is it just stale and needs a refresh?  
 Named parameters can be implemented in a library, however, in 
 my opinion they are useful enough to warrant a clean syntax 
 with language support.  I'd be willing to refresh the DIP so 
 long as I know the idea has not already been rejected.


There is https://github.com/dlang/DIPs/pull/71 which is a bit 
stalled< but solves most of the pain points and imho has good 
chances of being accepted. If you want to push that, feel free to 
help out on the PR and make it shine :)
Oct 01 2017
prev sibling parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler 
wrote:

 https://wiki.dlang.org/DIP88

 I'd like to see DIP88 (Named Parameters) revived.  Was this 
 proposal rejected or is it just stale and needs a refresh?  
 Named parameters can be implemented in a library, however, in 
 my opinion they are useful enough to warrant a clean syntax 
 with language support.  I'd be willing to refresh the DIP so 
 long as I know the idea has not already been rejected.


Has anything changed in 2019?

 Jonathan are you still interested to revive it?
Mar 21 2019
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 21 March 2019 at 07:20:09 UTC, sighoya wrote:

 On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan Marler 
 wrote:

 https://wiki.dlang.org/DIP88

 I'd like to see DIP88 (Named Parameters) revived.  Was this 
 proposal rejected or is it just stale and needs a refresh?  
 Named parameters can be implemented in a library, however, in 
 my opinion they are useful enough to warrant a clean syntax 
 with language support.  I'd be willing to refresh the DIP so 
 long as I know the idea has not already been rejected.


 Has anything changed in 2019?

  Jonathan are you still interested to revive it?


Yeah, just waiting to see if they fix the DIP process.
Mar 21 2019