6 ms·

> I'd refine some things if I were making a new language. Which parts would you change?

• steveklabnik 3y ago
  About a year ago I wrote this: https://steveklabnik.com/writing/too-many-words-about-rusts-function-syntax https://steveklabnik.com/writing/too-many-words-about-rusts-... I do think there's some good criticism of doing this, though, and so even a year later it's not clear to me it's a pure win. I am sympathetic to the vague calls to action by Aria et al. to improve the syntax for various unsafe features. I understand why we ended up where we ended up but I think overall it was a mistake. I am not sure I agree with her specific proposals but I do agree with the general thrust of "this was the wrong place to provide syntactic salt." (my words, not hers, to be clear) Ideally `as` wouldn't be a thing. Same deal, this is just one of those things that's the way it is due to history, but if we're ignoring all that, would be better to just not have it. I am still undecided in the : vs = debate for structs. I am sad that anonymous lifetimes in structs died six years ago, I think that would be a massive help. Probably tons of other small things. Given the context and history, I think the Rust Project did a great job. All of this is very minor.
  • lmm 3y ago
    > About a year ago I wrote this: https://steveklabnik.com/writing/too-many-words-about-rusts- https://steveklabnik.com/writing/too-many-words-about-rusts-... The = on functions idea is particularly interesting by comparison with Scala, which has shifted towards requiring = over time.
  • int_19h 3y ago
    That blog post says that "Rust doesn’t have named parameters, and possibly never will". Could you clarify why that is the case? In my experience, named arguments in all but the simplest - i.e. unary and some binary - function calls give a massive boost to readability. And for Rust specifically, they would also provide an easy, unambiguous way to "overload" functions, similar to Swift (I'm putting "overload" in quotes here because it's not really overloading, as parameter names simply become part of the function name). So, why weren't they considered, or if they were considered, why were they rejected so emphatically that you don't anticipate them showing up even in the future?
    • steveklabnik 3y ago
      Part of it is that it's not just named parameters: you should have a good story for default parameters too, and I think one or two others? Variadrics feels similar but separate. Oh, anonymous structs would allow you to emulate them while not adding the feature directly. Therefore, it ends up being a really huge thing, with lots of design space. This is combined with the fact that > they would also provide an easy, unambiguous way to "overload" functions Not everyone sees this as a good thing. Being slightly controversial, plus being really large, plus there being a lot of other things to do, would make me surprised if they ever land. Here's a link from eight years ago with a link to lots of other related proposals: https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831 https://internals.rust-lang.org/t/pre-rfc-named-arguments/38...
  • quicknir 3y ago
    FWIW, as a high performance C++ dev who likes Rust but considers unsafe the biggest issue by far, it's encouraging to see important folk within the project believe there are issues. Too often as a relative Rust outsider it feels like the attitude is "but the unsafe situation is okay because you'd barely ever actually need it!". Hope that unsafe continues to improve!
    • steveklabnik 3y ago
      I appreciate the kind words, but haven't been a part of the project for a while now. I hope they share this opinion, but I don't know.
      • quicknir 3y ago
        Ah okay, didn't know that. Good luck wherever you are!