<div dir="ltr"><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">As for your working implementation, link it if you are willing. Maybe some more knowledgeable folks would have insight.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2024 at 6:02 PM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com">rotan.olexandr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 20 апр. 2024 г. в 00:44, David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello again,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace"><a href="https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619" target="_blank">https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619</a></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">But yes, if it can be accomplished, it would be an incredibly valuable feature to have. I would like it.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2024 at 4:49 PM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings to the Java developers community.<br><br>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.<br><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>That's why I am reaching out to a Java community to gather opinions on this topic.</div><div><br></div><div>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.</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>