Raising the bar for introducing new syntax

[Centril]

Why would intuition matter here?

Intuition matters because I don’t want to get errors constantly from the compiler unless I can eventually train my brain’s internal type checker to recognize things and fix them before the error even happens.

[gbutler]

Wouldn’t the default intuition be: If I’m calling a function with more than 2 parameters not of the same type, I should name them? That would work like 99.99% of the time (my guesstimate ) even if it didn’t exactly match the proposed rule. In C#, where one can call any method/function with named parameters at your choosing, I always do that for any function with more than 3 parameters. The code just reads so much better. Personally, I wish it were just a requirement. I think if Rust had such a requirement in the language, two things would happen:

1. People would avoid creating crappy API’s like my example above
2. When people did create such crappy API’s, everyone would call them using the nice, unambiguous named-parameter syntax and even though the API was crappy, it would be readable in client code

Again, this is largely opinion, but, I believe I’ve provided some compelling arguments and examples for the “Righteousness of the Cause!”

[gbutler]

I would instead advocate a culture of using newtypes (such as for metres, time, etc…)

I 100% agree with this notion, but, I don’t think it alone solves the problem:

fn predict_mixture ( substance_a : SubstanceEnum,
                     substance_b : SubstanceEnum,
                     amount_a : Liter,
                     amount_b : Liter ) -> ( CompdoundEnum, Liter )

Which reads better?

let ( compound, amt ) = predict_mixture ( substance_a : HYDROGEN,
                                          substance_b : OXYGEN,
                                          amount_a : 0.00003,
                                          amount_b : 0.00025 );

OR

let ( compound, amt ) = predict_mixture ( HYDROGEN,
                                          OXYGEN,
                                          0.00003,
                                          0.00025 );

I would argue the former (especially for code you didn’t write and/or you are not 100% familiar with the API under use).

[scottmcm]

A better rule might be

If you said “heuristic” I might agree, but I’m not a fan of making anything here a “rule”.

People would avoid creating crappy API’s like my example above

There are way too many ways to write a crappy API for banning them to be effective. For one, I can bypass everything you just said by putting all my parameters in a tuple instead, which just makes it unambiguously worse.

In C#, where one can call any method/function with named parameters at your choosing, I always do that for any function with more than 3 parameters.

I loathe that in C# every parameter name is part of the public API because of this.

In C# I make structs to hold the arguments if it’s not a situation where positional is appropriate. I find that’s better anyway, since if there’re enough parameters that naming them helps, it also helps to be able to build them all up over time, rather than needing them all in the function call.

Which reads better?

Hmm, variable names with a common suffix? Sounds like it’s missing structure. How about this?

predict_mixture( (HYDROGEN, 0.00003), (OXYGEN, 0.00025) )

Conveniently that even seems to be the same tuple type that the function is returning…

(Could even take a slice of them, perhaps, depending on what the method is supposed to be doing, where using stucture like this is clearly better than fn (&[SubstanceEnum], &[Liter]).)

[CAD97]

Since this drifted onto named arguments:

The problem with (implicit) named arguments is that the calling site context of a value may be different than the use sure name. The poster example in Swift would probably be

func send(message: Message, from source: Actor, to target: Actor)

In this case, send(message:source:target:) would also make sense, but send(message:from:to:) (arguably) reads better. Actually, it should probably be send(:source:target:), as the fact that the first parameter is Message is in the type, and the Swift API recommendations say that you shouldn’t repeat the type as an argument name.

---

Though I agree that the barrier should be high to getting features into the language, I don’t agree that it isn’t already. For one, writing a good RFC is already a large hurdle to overcome. Many suggestions die a fast, quiet death because someone tossed it out here or elsewhere, but nobody was enthused enough to write up a proper RFC. Most of the recent big-ticket changes that have gone through RFC have been language (or libs) team proposals, as well; the ones that come to mind are the modules and async.

Both of these come from a position of a weakness in the language: modules because Rust never intended to be revolutionary on the module front – and the last version I heard about was quite minimal, and async because one of Rust’s goals for 2018 is to be great choice for web-connected workers, which requires good, powerful, and ergonomic asynchrony.

(If you disagree that the modules change is small, here is the four bullet point version:

• Allow crate-local paths to start with crate::
• Allow paths to start with an external crate linked in by the rustc command line invocation (used by cargo)
• Include linked in crates in the prelude names implicitly glob imported into any namespaces
• Allow file.rs to have submodules as if it were file/mod.rs (currently, it can’t have any)

That seems minimal, incremental, and like a simplification to me; the root module no longer is special and information in cargo doesn’t have to be repeated.)

It only feels like a lot because there is a lot of enthusiasm about Rust from the community. That enthusiasm also helps to filter the RFCs to the ones that have a decent chance of improving the language. Almost every libs RFC is immediately hit by “why not an external crate” (those that don’t because they’ve addressed it), and even many language ones as well.

---

I do agree that accepting RFCs faster than they can be implemented is a dangerous road. That’s why I threw my hat in the “Rust 2018 should be boring” ring. But a key part of Rust’s philosophy is that “stability without stagnation”, so new ideas will hopefully always be coming.

As a final side, it’s very easy to do “armchair” language design. I’m not free of guilt here. It’s much easier to try to get your favorite feature (for me, refutable/guard let) into an existing language than make your own (plus convincing others to use it), and Rust is by far the most accepting of any idea from an outsider to language design. While we’re still in that position of hip new language that is open to community suggestions, and especially while we’re the “best” with those qualifications (for some (conflicting) definitions of “best” by the crowd), we will attract suggestions.

It’s our job as an engaged community to encourage good, thought out discussion and design. I hope we can continue to do a good job at it.

---

(Apologies for the wall of text; TL;DR change is scary but we should always evaluate objectively and critically (in the good way))

[MajorBreakfast]

Consider reviving the named arguments thread

[Pre-RFC] named arguments

This is my first attempt at an RFC, any feedback is welcome Keyword arguments have been proposed multiple times in multiple forms in the past and had been postponed for after the 1.0 release. 1.0 has been released and things have settled a bit, so I thought it would be a good time to jump-start the discussions more actively again. Let me know if some parts need more clarification / details. Relevant discussions “Wishlist” issue postponed RFC: keyword arguments postponed RFC:…

Edit: I just browsed through this and whoaa that’s a really long thread. The summary post in (roughly) the mid of it is a nice read.

[dan_t]

If an RFC has many people disagreeing, either via comments or votes, that should at least trigger some more extensive discussion about why the language team still went ahead. At the moment it just feels like a dismissal of the people who are against things.

I’ve more the feeling, that quite a few people feel a bit too much entitled, that their opinion has to be considered.

Just because the language team does open discussions about language features, doesn’t mean that every contribution of people without experience in language design is valuable.

IMHO the team still does a great job in discussions and responds on different viewpoints. But the expectations what the language team should do are way too high.

I think because the language team has opened up that much, the expectations are also rising. It seems that you can’t be too much open.

[MajorBreakfast]

open discussions about language features, doesn’t mean that every contribution of people without experience in language design is valuable

That always happens of course. In such cases, I think the perfect response is to either post a short bullet list with reasons or (even better) to link to a previous discussion or comment that addresses the point.

(BTW IMO you should change “that their opinion has to be considered” to “that their opinion is what counts”. I think the lang team is actually considering every opinion because I’ve the impression that they always read all the comments)

[dan_t]

(BTW IMO you should change “that their opinion has to be considered” to “that their opinion is what counts”. I think the lang team is actually considering every opinion because I’ve the impression that they always read all the comments)

Yes, bad wording on my side.

[phaylon]

I’ve more the feeling, that quite a few people feel a bit too much entitled, that their opinion has to be considered.

So, in your opinion I’m not allowed to ciriticise the current process? Asking for improvements is entitlement?

The language team has always been about involving the community. If that has changed, they should let people know. And yes, after spending days or weeks discussing a topic, it would be nice to have some form of result that you can put in context of your own ideas.

It’s quite disappointing how criticism is treated these days.

[gbutler]

If you said “heuristic” I might agree, but I’m not a fan of making anything here a “rule”.

Given that the definition of heuristic is, “a commonsense rule (or set of rules) intended to increase the probability of solving some problem”, I don’t see how heuristic is a better word. In fact, I’d say it is a worse word for the concept being described.

I can bypass everything you just said by putting all my parameters in a tuple instead,

Yes, you could. But that requires more work on your part. Also, personally, I don’t think declaration of tuples with greater than 2 or 3 members should be permitted in function declaration parameter position which would take the “work-around” off the table.

I loathe that in C# every parameter name is part of the public API because of this.

Why? How does having n named parameters be part of the public API differ in complexity from having a public structure with n named elements be part of the public API of a method? The latter has more complications, not less. In order to never have functions/methods with many parameters, you suggest always creating a structure instead? That sounds really counter-productive and I can already hear the wailing and gnashing of teeth.

In C# I make structs to hold the arguments if it’s not a situation where positional is appropriate. I find that’s better anyway, since if there’re enough parameters that naming them helps, it also helps to be able to build them all up over time, rather than needing them all in the function call.

You are changing the discussion from how to best call a function that someone else wrote to how best to write/design the function. In most cases, I would agree with you here on design of methods/functions, but, not always. If you think it is always, then, why not disallow it (which, by the way, I never suggested)?

Hmm, variable names with a common suffix? Sounds like it’s missing structure. How about this?

Again, my comment is about how best to call methods written by others that have lots of parameters - it has nothing to do with how best to design a method/function.

So, just to be clear, when I say that Rust should support/require named parameters in method calls when the method has over a certain threshold of parameters, I am talking about how best to consume such methods written by others. I don’t seek to disallow methods with lots of parameters. I don’t seek to encourage methods with a lot of parameters. If you have a real need to write a method with a lot of parameters, then, the correct calling convention should be named parameter style. That is what I am advocating.

If your answer to that is, “Well, you should NEVER be creating methods/functions with lots of parameters” (which I disagree with), then why allow methods/functions with lots of parameters to be created?

TL;DR: If Rust allows high-cardinality parameters on functions, then, it should require named parameter calling convention for such functions. If the argument is it should never be done (which I disagree with) then don’t allow such methods to be defined.

[Centril]

I believe this would all work a lot nicer if the discussions and opinions of the language team weren’t rather secret.

I’ll take this feedback with me to the next meeting.

If that has changed, they should let people know.

It hasn’t changed! There are just very busy people in the teams, so sometimes it takes time to give feedback. I think the Async trait RFC shows that the teams listen, and do change their proposals or often do ask for changes given community feedback.

If an RFC has many people disagreeing, either via comments or votes, that should at least trigger some more extensive discussion about why the language team still went ahead.

I think this happens; In the recent try RFC, @scottmcm wrote a long review discussing the ups and downs and took the feedback into account.

I’ve the impression that they always read all the comments

I try to read as many comments as I can, but I’m just a shepherd Of course the teams don’t all read literally every comment (because that would be everything they could do in that case), but they do as best they can.

[phaylon]

I’ll take this feedback with me to the next meeting.

Thanks! Even just some small feedback for the community towards what discussions would be more productive would help I believe.

It could allow for a lot more focussed back and forth I think.

[MajorBreakfast]

Of course the teams don’t all read literally every comment

^^’ Yes. “they read all the comments” sounded better than “at least one or more language team members involved with the particular feature read(s) the comments” In particular I am happy how the async/await story is handled. A lot of feedback is given and a lot of constructive discussion is going in these RFCs.

[mbrubeck]

[Moderator note: Could any further discussion of named parameters please go into a separate thread? The digression is making this thread harder to follow.]

[withoutboats]

The language team has always been about involving the community. If that has changed, they should let people know.

Aaron is my boss and we have 1:1s every week. The number 1 thing we spend time talking about is community feedback & how we need to adjust our goals, strategies, and designs for the projects I’m working on in accordance with that feedback. Participants in internals and the RFC process have a huge influence over the direction of the project.

But also keep in mind that writing posts takes time and effort, and the number of concurrent discussions (and the length of each discussion) has only grown over time. It’s frequently the case that I incorporate feedback from users into the next iteration of a proposal without having time to respond in specific to many (or sometimes even any) particular user comments on that issue.

[macronaut]

I think @mgeisler is referring to things like this being introduced to the language when it has no benefit to most of the people using Rust on a regular basis: https://github.com/rust-lang/rust/pull/47947

[gilescope]

Wouldn’t it be nice to be able to specify code transforms that would allow you to upgrade your existing usage to the new usage. Like structural search and replace in resharper. Then the rls could say this code needs upgrading - press alt-enter and I will fix it up for you.

[masonk]

I agree with the general sentiment of the OP, although I don’t have any specific criticism of any specific feature proposal.

Language concision is a common good. A small language benefits everyone. Yet preserving concision is a tragedy-of-the-commons situation. The responsibility for keeping the language small is diffuse, whereas the proximate benefits to each individual of shepherding his favored proposal into the language is acute.

Rust’s RFC process is local hill climbing. From any given state, it can find a better language, but it also risks finding a trap: no guarantee of global optimality. From a given state of the language it’s possible to look at almost all of these proposal and agree that they’re locally beneficial to a language without the features. Yet, if you look down the road to a future where all of these proposals are approved, you might have preferred a future where none of them are.

There’s no formal way to prevent this kind of problem. Best you can do is to add a “size” term to your cost function to regularize in favor of a smaller language. So far, I think the Rust leads have lavished the language with extravagantly good judgment and discipline, and I trust them a lot. But the worry is always there.

It might help to make small size an explicit goal of the language?

Edit: just took a look at https://github.com/rust-lang/rfcs/pull/1925. Doesn’t really bother me. It’s not a new feature and it doesn’t increase cognitive complexity . There is a small chance it makes the parse more difficult.

[jjpe]

From any given state, it can find a better language, but it also risks finding a trap: no guarantee of global optimality.

It’s worse than that: Given the multidimensionality of the design space of programming languages (e.g. memory/type safety, ergonomicity, runtime performance, compile time performance) there is a very strong likelihood that there is no actual global optimum to be found at all.