Allowed type of expression as default value of method parameter

[David Alayachew]

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/20240419/4df49c40/attachment.htm>