5 ms·

I totally agree. Named parameters are one of those language features which once you use it, you don't want to go back. Similar to C-like syntax and ADT's / ex

• DaiPlusPlus 5y ago
  Named parameters in C# make refactoring far less error-prone too. Consider a method that accepts two int parameters: “DeleteUser(int tenantId, int userId)” - if a call-site was DeleteUser(1,2) and you swapped the parameter arguments you’d be in trouble. Having “DeleteUser(tenantId: 1, userId: 2)” makes code not only safer, but also far more self-documenting.
  • skohan 5y ago
    At the risk of being pedantic, I would use separate types there for the id's to avoid this kind of issue, but in general I agree with your point
    • lostmsu 5y ago
      What would you do about a slice function? Without the parameter names you won't even see if the second parameter is length of the slice or its right end.
      • DaiPlusPlus 5y ago
        In C# (prior to C# 8.0) without parameter names you would get an ambiguous overload error (and overload resolution is strictly by types, not by names - except for extension-methods). C# 8.0 side-stepped this problem by adding an explicit range operator. However I feel the best approach is to have first-class language support for parameter-arguments-to-type homomorphisms (e.g. `TArgs<YourMethod> args = new( arg1, arg2, arg3 ); YourMethod( args );`).
      • skohan 5y ago
        Yeah I agree there are examples where types are not enough to disambiguate arguments.
    • kevinmgranger 5y ago
      There's an interesting commonality here: syntactically, `function(Type1(int), Type2(int))` and `function(type1=int, type2=int)` are almost identical. They differ in that types can help guard against errors elsewhere (within or without that function call), but named arguments let you not care about the order. I've always wondered: what if languages had no guaranteed argument order, but let you skip explicit naming if all parameters were different types? What kind of idioms would that create? Would it mean more newtypes? Would that be cumbersome?
      • skohan 5y ago
        It's an interesting thought. Personally I don't mind explicit ordering, since it's just one more way to cross-check correctness. Also I can imagine leaning on the type inference to resolve which argument is which might not be the best for compile times.
      • singron 5y ago
        I'm not aware if this exact idea, but dependency injection frameworks have a similar concept where the parameter order doesn't matter and the framework figures out the right order when it calls functions based on the types. It's probably really complicated at the language level if it also has to interact with overloading, subtyping, and generics.
  • bobbylarrybobby 5y ago
    In theory, those two types shouldn’t be ints, but rather separate int wrapping types TenantId and UserId so that they can’t be mixed up at all
    • DaiPlusPlus 5y ago
      Unfortunately hardly any ORMs support that (especially not EF, argh), and writing custom value-types is a painful experience given C# (still) doesn't support strict typedefs nor mixins.
      • kevinmgranger 5y ago
        If only structs were inheritable, then you could roll your own `struct Wrapper<T>` with operators for implicit conversion, equality, etc, and then extend it with just the name and type. Wouldn't help with the EF pain point though, and I'm sure it might confuse newcomers initially.
        • DaiPlusPlus 5y ago
          Inheritance shouldn't be abused to make-up for the lack of true mixins, though.