We are talking about completely different features for completely different problems. They are complimentary. Your proposal doesn't help the cases I'm talking about, and vica versa.
You are talking about sugar for naming different functions, for different functions
I am talking about sugar that avoids the need for multiple wrapper functions, where you want the same function with several tiny variations.
e.g.
currently in Rust we need separate functions "as_slice(), slice_from(x), slice_to(x), slice(from,to)" ..
fn slice(&self,from:uint,to:uint) { .. the meat.. }
fn slice_from(&self,from:uint) { self.slice(from, self.len()) }
fn slice_to(&self,to:uint) { self.slice(0,to) }
fn as_slice(&self,from:uint, to:uint) { self.slice(from,to); }
.... notice how many times 'slice,from,to' are repeated.
With Default+Keyword Args, you'd replace all 4 functions with one...`
fn slice(&self, from:uint=0, to:uint=self.len()){.. the meat..};
Now you would just omit or name parameters to get ...
foo.slice() same as self.as_slice() was. from,to omitted so take default
foo.slice(to=10) same as foo.slice_to(10) was'. name arg 'to',skip defaulted'from'
foo.slice(2,5) same as foo.slice(2,5) was
foo.slice(5) same as foo.slice_from(5) was, to=self.len(). '5' is positional arg 'from'
It becomes trivial to add these conveniences.
My proposal - has precent in many languages - better leverages the code and names you create to avoid a certain set of trivial wrappers.
It reduces navigation time because you have less names to search through, and less definitions to jump through. Less symbols in the autocomplete.
Similarly my draw_axes(matrix), draw_axes_color(matrix, colour) draw_axes_color_size(matrix,colour,size) .. In C++ these could just be one function void draw_axes(matrix,u32 color=0xffffffff,f32 size=1.0f);
How are you going to support this overloading when you have default arguments?
C++ has overloading AND default arguments , and it works. These are different features
void draw_axes(Matrix& m, u32 color=0xffffffff, float size=1.0f)
void draw_axes(ColumnMatrix& m, u32 color=0xffffffff, float size=1.0f)
.. You write as many variations as you want, with different numbers and types of args so long as its unambiguous..
The default is None? Then you have to wrap the def arg in Some.
No, I never suggested that. That is a (terrible) alternative idea people use to argue AGAINST the feature I'm after. Passing an optional argument as an option is more verbose and adds complexity to the routine. I'm talking about leveraging simple cases, where a simple push of a value avoids needing a whole extra function or piece of logic.
my C++ solution for unwrap_or() would also be different:-
in C++ that is an overload - selecting a different function by passing a different number of args - not a default parameter on the same function.
It could look like this..
template<class T>
class Option {
bool is_some;
T value;
...
T unwrap() {assert(this->is_some); return this->value; }
T unwrap(T default) { if (this->is_some) return this->value; else return default;}}`
... given the conflicting demands, either one scheme will confuse people coming from different regimes. The haskell people all want straightforward currying, the C++ people want trailing defaults, and so on.
… which at least to my mind fit better with imperative+method syntax.