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.

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

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.

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

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.

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?

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

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.

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 :)

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