11–20 of 119 posts
> I’d like a language that can contextually resolve enums, so I can just type something like calc_formula( ia, ib, is_gain ).
Swift does this and it should be considered for any new language design. Enum.variant can be shortened to .variant, including for variants with data in them, .variant(arg). Perfect solution, because the dot is an autocomplete trigger.
In python, I love keyword-only arguments for this. Then the caller has to write: v = calc_formula(ia, ib, is_gain=true) You also have the option of defining a default value for the argument so the old call-sites don't even need modification.
In C++ I’ve gotten in the habit of `enum class is_gain : bool { no, yes };` so the call site is `v = calc_formula(ia, ib, is_gain::yes);`. An advantage is that such stron Boolean-like types can be passed repeatedly and maintain their type safety.
enum gain_type { enable_gain, disable_gain };From the article: > I’d like a language that can contextually resolve enums, so I can just type something like calc_formula( ia, ib, is_gain ). Swift does this and it should be considered for any new language design. Enum.variant can be shortened to .variant, including for variants with data in them, .variant(arg). Perfect solution, because the dot is an autocomplete trigger.
As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…
https://pdimov.github.io/blog/2020/09/07/named-parameters-in...
IntelliJ solves this nicely by showing the parameter name at call sites, effectively making it look like the language has named parameters.
Fully agree. No need to change the source code to fix what isn't broken.
As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…
This even works in latest MSVC as well as clang and gcc! https://pdimov.github.io/blog/2020/09/07/named-parameters-in...
Earlier quoted context omitted.
Fully agree. No need to change the source code to fix what isn't broken.
While I think parameter names at all call sites is the right solution, I don't think it's good enough to have this in the IDE alone. I still have to review code online that says `add(a, true)`, even if IntelliJ showed me `add(a, ignore_negatives:true)`.
And in case of really large number of parameters, one would generally pass either a map or (in older code) a proplist: #{is_gain => true, other_param => 42, ...} or [{is_gain, true}, {other_param, 42}, ...]. There is no beautiful syntax for destructuring all that stuff with default values, unfortunately.
As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…