[lpil]

When argument variable names and labels are combined you have two problems:

1. Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API. Gleam is designed to make sure that APIs are always carefully thought about and designed as appropriate.

2. Renaming a variable becomes a breaking change. We don't believe that renaming a variable should ever result in a semver major version bump.

[troupo]

> Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API.

1. Not every code is an API. And APIs exist in multiple languages that don't have labels

2. If you wanted named parameters, you could go the C# way: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

3. Since Gleam doesn't enforce labels or check labels in any way, it doesn't "make sure APIs are carefully thought out". Labels will be just as random and accidental as parameter names following the whims of the programmer who decides to use them

> Renaming a variable becomes a breaking change.

So does renaming a label.

[yaglo]

1. Every class/method/function/whatever declaration is an API, doesn't matter if it's internal or which language it's written. 2. Why do you think it's better? It looks like it tries to cater to everyone, and leads to inconsistent API usage and requires teams to agree on linting rules and use tools to enforce consistent coding standards. 3. It's a tool for _you_ to design good APIs that are clear. Languages without named arguments don't give you this tool.

> So does renaming a label.

In languages without this feature, any renaming breaks the API, unlike the ones with distinct internal and external names. This is not the same.