Allowed type of expression as default value of method parameter

Sat Apr 20 00:13:15 UTC 2024

Here is a link: https://github.com/Evemose/jdk/tree/default-parameter-values

On Sat, Apr 20, 2024, 03:11 ІП-24 Олександр Ротань <rotan.olexandr at gmail.com>
wrote:

> Oh, thank you. I was wondering why "reply all" didn't work
>
> On Sat, Apr 20, 2024, 03:09 David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> You have sent it to only me again. You have not included the mailing list.
>>
>> If your email client is automatically only including me, you can manually
>> include all recipients you wanted to include. For example, you can just put
>> compiler-dev at openjdk.org into the TO section of the email.
>>
>> And btw, here is how our discussion on this thread looks to the outside
>> community. Click Next message on the top of the page.
>>
>> https://mail.openjdk.org/pipermail/compiler-dev/2024-April/026123.html
>>
>> And here is how our other discussion looks.
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/121787.html
>>
>> Notice how most of your responses are not visible? You can use the
>> archive to make sure that your reply is visible. Here is a list of all
>> mailing lists.
>>
>> https://mail.openjdk.org/mailman/listinfo
>>
>>
>> On Fri, Apr 19, 2024 at 8:04 PM ІП-24 Олександр Ротань <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Here is a link:
>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>
>>> On Sat, Apr 20, 2024, 02:59 ІП-24 Олександр Ротань <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Oh, I see. Still learning about how this mailing stuff works. Thank you!
>>>>
>>>> On Sat, Apr 20, 2024, 02:58 David Alayachew <davidalayachew at gmail.com>
>>>> wrote:
>>>>
>>>>> You only responded to me. You must click Respond All, otherwise, only
>>>>> I will see it. Reply to my message again, but do Reply All.
>>>>>
>>>>> In fact, through all of the conversations we have been having, you
>>>>> have only been responding directly to me, which means that only I could see
>>>>> it. I did Reply All in my responses so that the rest of the community could
>>>>> see the discussion.
>>>>>
>>>>> Make sure to do Reply All from now on when sending anything on these
>>>>> mailing lists.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 7:32 PM ІП-24 Олександр Ротань <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Here is a link:
>>>>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>>>>
>>>>>>
>>>>>> сб, 20 апр. 2024 г. в 02:04, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>> Unfortunately, I don't have too much more to say, as this is a
>>>>>>> subject I am not very knowledgeable about. I only know enough to say what I
>>>>>>> have already, as well as point to videos that discuss this subject.
>>>>>>>
>>>>>>> As for your working implementation, link it if you are willing.
>>>>>>> Maybe some more knowledgeable folks would have insight.
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024 at 6:02 PM ІП-24 Олександр Ротань <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello! Named arguments are much more complex as they require both
>>>>>>>> declaration-site and invocation-site manipulations. Just default values are
>>>>>>>> much easier, if deal with them in a way kotlin does using compile-time
>>>>>>>> overload generation. The only question I am thinking on right now is should
>>>>>>>> they appear in AST (like default constructor), or added after ( during
>>>>>>>> Enter phase or along with synthetic methods). Second option would be a bit
>>>>>>>> harder to implement, while the first one took me just 100 lines of code (i
>>>>>>>> have a working implementation right now).
>>>>>>>>
>>>>>>>> сб, 20 апр. 2024 г. в 00:44, David Alayachew <
>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>
>>>>>>>>> Hello again,
>>>>>>>>>
>>>>>>>>> Default parameter values, while maintaining backwards
>>>>>>>>> compatibility with regards to overload selection, is a very difficult task.
>>>>>>>>> I don't see a way that it can be done while maintaining backwards
>>>>>>>>> compatibility and without turning all methods into virtual dispatch. Brian
>>>>>>>>> Goetz spoke of it in this video. He is talking about named arguments at
>>>>>>>>> first, but then he addresses default values later.
>>>>>>>>>
>>>>>>>>> https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619
>>>>>>>>>
>>>>>>>>> But yes, if it can be accomplished, it would be an incredibly
>>>>>>>>> valuable feature to have. I would like it.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 19, 2024 at 4:49 PM ІП-24 Олександр Ротань <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings to the Java developers community.
>>>>>>>>>>
>>>>>>>>>> I am currently working on default parameter value support for
>>>>>>>>>> java. Surprisingly, implementation of this feature turned out really simple
>>>>>>>>>> and non-invasive, no more than a few hundred lines of new code.
>>>>>>>>>>
>>>>>>>>>> The question I am asking is, should default parameter values be
>>>>>>>>>> only compile-time constants (or null), or should expressions be also
>>>>>>>>>> allowed? My opinion is, although this is not a popular choice among
>>>>>>>>>> existing programming languages, any kind of expression that could be used
>>>>>>>>>> in variable initializer, should be allowed as default value.
>>>>>>>>>>
>>>>>>>>>> The reasoning behind this is pretty simple. The main goal of
>>>>>>>>>> default parameter values, as for me, is to eliminate loads of boilerplate
>>>>>>>>>> method overloads and problems they bring during development. In almost all
>>>>>>>>>> popular languages today, for various reasons, if a developer wants to make
>>>>>>>>>> default parameter value runtime-evaluated, they just have to manually
>>>>>>>>>> overload method explicitly and pass runtime-evaluated expression as
>>>>>>>>>> parameter, which essentially is opposite to what default parameter values
>>>>>>>>>> are needed for
>>>>>>>>>>
>>>>>>>>>> On the other hand, runtime-evaluated default parameter values
>>>>>>>>>> seem to be an unpopular option in currently most popular languages, and I
>>>>>>>>>> am wondering maybe I am missing the point why, because for me, there
>>>>>>>>>> virtually isn't any reason to forbid them.
>>>>>>>>>>
>>>>>>>>>> That's why I am reaching out to a Java community to gather
>>>>>>>>>> opinions on this topic.
>>>>>>>>>>
>>>>>>>>>> PS: Regarding the way to implement default values, I decided to
>>>>>>>>>> go with an overload-based approach. This will help to preserve backward
>>>>>>>>>> compatibility, and also is much easier to implement then call-side
>>>>>>>>>> parameter injection, which reduces chances of unexpected errors.
>>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240420/d58ea201/attachment.htm>