Re: DIP 1043---Shortened Method Syntax---Accepted
On Saturday, 24 September 2022 at 08:45:33 UTC, Dukc wrote: Good reasoning from Max. Thanks Max for the DIP!
Re: DIP 1043---Shortened Method Syntax---Accepted
On Thursday, 22 September 2022 at 01:28:11 UTC, Doigt wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. It's one of those things that aren't necessary, but bring some small "quality of life" kind of change to the code we write. At least in my opinion, I quite like it, the same way I like how I can call a parameter-less function without parentheses. It actually makes code very hard to read Is it a field? is it a function, does it have arguments, or maybe it is just a static function, maybe it is a property, oh shoot i have to waste time trying to figure out what it is It is same story with imprts, so now i exclusivly use named import ``import xxx = my.package.here`` ``xx.my_global_function();`` This way when i read code, i know exactly what is doing what and from what module This shortened method syntax is the same, it is a method, not a field, therefore it should require ``()``, i personally never omit it from the way i write function in my code, calling a function this way: ``this_is_a_function`` is imo very dangerous, i wish it was gone from the language
Re: DIP 1043---Shortened Method Syntax---Accepted
On Saturday, 24 September 2022 at 08:45:33 UTC, Dukc wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. If there is no reason to reject an already-implemented feature, there's no reason to to reject it as non-implemented either. Not just already implemented, but reviewed and merged by existing maintainers. It shows the feature was considered by trusted colleagues to be worth adding as a preview. If it feels like it's too much work to implement an otherwise good DIP, it should be accepted on the condition that someone does it, not rejected IMO. DIPs for semantic features are much easier to review when there's an implementation so people can play with the feature and see how it interacts with the existing language. Basically the burden should be on the advocates to make their case, not on the maintainers to investigate an idea.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. Excellent! The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. If there is no reason to reject an already-implemented feature, there's no reason to to reject it as non-implemented either. If it feels like it's too much work to implement an otherwise good DIP, it should be accepted on the condition that someone does it, not rejected IMO. Even if the maintainers don't have time to implement something themselves, it still lowers the bar a lot for someone else to do it when there is a promise to accept any sound implementation. Walter accepted with a suggested (not a required) enhancement: It could be even shorter. For functions with no arguments, the () could be omitted, because the => token will still make it unambiguous. As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. Good reasoning from Max.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. It's one of those things that aren't necessary, but bring some small "quality of life" kind of change to the code we write. At least in my opinion, I quite like it, the same way I like how I can call a parameter-less function without parentheses.
Re: DIP 1043---Shortened Method Syntax---Accepted
On 21.09.22 12:39, Mike Parker wrote: The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. The benevolent way to read that is that Atila liked that he could easily try out the new feature and judge it more fairly because of that. The mean way to read it is that Atila employs some circular reasoning: Accept the preview implementation, deferring to the DIP process to catch a bad proposal. Accept the DIP, referring to the preview implementation as justification.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: For example: T front() => from; becomes: T front => from; I kind of agree with Max's contention, but nonetheless, I quite like it.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 13:56:35 UTC, Meta wrote: On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md That's awesome! Congrats to Max. And to Adam. I believe it's his implementation behind the preview switch.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md That's awesome! Congrats to Max.
Re: DIP 1043---Shortened Method Syntax---Accepted
On 21.09.22 12:39, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. Walter accepted with a suggested (not a required) enhancement: It could be even shorter. For functions with no arguments, the () could be omitted, because the => token will still make it unambiguous. For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. Great news! :)
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md
DIP 1043---Shortened Method Syntax---Accepted
DIP 1043, "Shortened Method Syntax", has been accepted. The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. Walter accepted with a suggested (not a required) enhancement: It could be even shorter. For functions with no arguments, the () could be omitted, because the => token will still make it unambiguous. For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is.
