There have been several discussion on this, I believe.
The issue, IMO, is that there is no limiting principle. By this I mean, suppose we permit = title. Shouldn’t we also permit = "Title: \(title)"? And also = title + " " + altText? And why not any arbitrary expression?
Taken to its logical end, this ends up being pure sugar for code that you can write within the body of the function, so long as you don’t try to reference arguments that follow the current argument. It doesn’t seem like this would improve readability or safety, so it doesn’t seem like an overall win to me.
This also has the complication that Swift has no model for side-effect-free/“pure” functions at the moment. Presumably we would not want default values to allow side effects.
The same argument can be made for default parameters: it's just sugar. The proposed features covers "second-tier" defaults as well, getting rid of the same bloat (optional + if/guard to check and set) that default parameters to away with for "first-tier" defaults.
No. First, because the bar for adding new sugar is much higher than that for keeping existing ones. Second, because to be able to use “Optional + check-and-set,” you need to be able express some sort of default at all in the first place.
I will add that some kind of default arguments is also needed to get the #file, #line and other compiler supplied placeholders to work for diagnostic functions.
You can call functions in default values, and you can use operators. You just can't reference self or other parameters of the current function.
If some day we add the concept of a pure function, we'll need to restrict default values of pure functions to a pure expression (something I need to add in my exploratory proposal), but I think that ship has already sailed for regular (non-pure) functions.
Default arguments are inlined code as of Swift 4. That doesn’t mean they can’t call things that are internal-but-ABI, but it’s not going to be the usual thing. As @dabrahams has pointed out in the past, a default that the user can’t specify explicitly still has to be documented, and is kind of a jerk move anyway.
I just ran into a scenario where this would be useful and thought I would look it up.
Any update or solid arguments against this seeing how other languages already have the ability to do it?
In the four years since I opened this thread, I’ve had a handful of times when I wanted this. Definitely still in favor of making it possible.
I think that, since I started this thread, there was a change where default argument values are available in the public interface of functions. It feels like that would bring us closer to being able to do this, no?