Allowed type of expression as default value of method parameter

[David Alayachew]

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