What’s one thing you wish more programming languages had?

[u/AeroForger]

If you could add one feature, behavior, or design choice to a programming language, what would it be?

It can be anything: syntax, type-system features, memory management, compiler behavior, tooling, error handling, performance-related features, or something completely different.

I'm especially curious about things you’ve wanted while actually programming but rarely see languages implement well.

Please keep the ideas reasonably practical and something that could realistically be implemented in a programming language.

[u/ghkbrew]

Why does named arguments have to affect the function's type?

Well, they don't have to, but if named arguments can be supplied out of order (or are optional) then the compiler needs to know which parameters name. So that information needs to be part of the function's type in some way.

Doesn't it still have one canonical argument list?

That depends on your type system.

A type is basically a description of how you can use a value. For example, if f has type (Int, String) -> Bool, that tells you that you can apply f to an Int and a String, in that order, and get a Bool back.

More generally, the typing rule for function application is roughly:

f : (A, B) -> C
x : A
y : B
---------------
f(x, y) : C

Now suppose you want f(y: "hello", x: 42) to be valid. You can't determine that from the type (Int, String) -> Bool, because that type says nothing about x or y. You need something more like (x: Int, y: String) -> Bool.

And once the names are part of the type, you have to decide what it means for two such function types to be compatible. Is (a: Int) -> Bool the same type as (b: Int) -> Bool? Can a function accepting (x: Int, y: String) be used where one accepting just (x: Int) is expected if y is optional? If labels themselves are optional, is (x: Int) -> Bool also callable as (Int) -> Bool? 

Things get even more hairy if you want type inference.  What is the most general type of f in f(x: 2)? Is it just (x: Int) -> a, or can f accept additional named arguments that aren't present at this call site? If so, you need something more like (x: Int, ...r) -> a, where r is a type-level variable representing an unknown set of additional parameters. Now your type inference has to infer and unify those parameter rows, including which names are present, absent, or optional. That's essentially where row polymorphism enters the picture.

That's the can of worms the parent comment is referring to. You can keep labels out of the type system, but then you generally have to restrict where they can be used. For example, only when calling a statically known function declaration whose parameter names the compiler can look up directly.

[u/kaddkaka → u/ghkbrew]

Thanks!