I was wondering if argument labels for methods/functions have ever been considered for Rust so far, an example would be the Swift programming language.
I saw that some people have been working on it as a crate, but I was generally wondering if the community supports the idea or not.
I like Swift, but prefer Rust. However, argument labels I always thought to make code more readable; and it doesn't necessarily require one to write more, as argument labels can also be "dropped".
My experience with C# is that allowing mixing is a mis-feature, though I'm not familiar with Swift's version, so it might be better there. But named ones you can't reorder and positional ones you can't rename both feel bad to me.
My personal wish is that we get enough sugar and ergonomics features that if you need a whole bunch of arguments, you just use a struct. (That works just like a struct, that lets you build up the struct over multiple lines or even functions, that gives you a way to offer multiple different pre-canned combinations, etc.) Maybe that means anonymous structs, maybe that means function sugar for making a struct, maybe that means function sugar for calling with a struct literal, maybe that means more convenient trait deriving, maybe that means more FRU options, maybe that means sugar for exploding a struct, who knows.
I would argue that we should emphatically discourage any function that takes two bools, so that it never comes up. It would, conveniently, also remove weird cases like someone somehow bringing a guest to the party without actually attending...
I agree this is not good code. I didn't give much thought to my example when I created it, but now that you've pointed out it's a badly designed API, I'll use this opportunity to say that IDE parameter hints still helped with the readability of this function.
While looking around for a better and less contrived example, I noticed that nearly all of the functions in the rust stdlib take only 1 argument or use a builder pattern. So in nearly all cases, function parameter hints aren't necessary to understand the code. But I am still arguing that can help readability. Here are a few more examples: