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