6 ms·

I'm glad that Rust has no `auto`. I find this: fn map<U, T, F, I>(it: I) -> impl Iterator<Item=U> where I: Iterator<Item=T>, U: From<T> {

I'm glad that Rust has no `auto`. I find this: fn map<U, T, F, I>(it: I) -> impl Iterator<Item=U> where I: Iterator<Item=T>, U: From<T> { it.map(|t| From::from(t)) } infinitely more readable than fn map<U, T, F, I>(it: I) -> auto where I: Iterator<Item=T>, U: From<T> { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator<U>`, even though the actual type cannot be named because of the anonymous closure. The second one leaves me guessing what the return type is. If the actual type cannot be named, it is rarely the case that this is all there is to it. Usually, users are expected to use that type "somehow" (it is a `Range`?), and that means that there are some interfaces that these types implement.

EvenThisAcronym 6y ago
Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.
- kibwen 6y ago
  That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)
  - StillBored 6y ago
    Which helps out the documentation side, but destroys code readability. Particularly since rust users appear to really like creating long method call chains, frequently with a closure or two sprinkled in. Take this "example" https://github.com/diwic/dbus-rs#server https://github.com/diwic/dbus-rs#server. For a beginning user of the library that is nearly impenetrable without breaking each of those calls apart. Even if your pretty familiar with rust you still have to break it apart and explicitly place the types in the "Let" statements to know the intermediate types in order to look up the method documentation. This style of coding is so bad, that it turns out the example has a syntax error. Good luck finding it without the compiler or a quality editor though. Worse, the example doesn't actually work due to further bugs. Anyway, rust by itself may be ok. Some of the core concepts are good, but the way people are using it is leading to inpenteratble messes of code. Code like the above combined with what seems excessive/unnecessary use of generics create problems for more advanced usage when it comes to learning and modifying a piece of code. Some people have blamed this on the language's learning curve, but I'm not sure that is appropriate. By itself the language is fairly straightforward, the difficulties occur when people are working around the language and pile in masses of write only code. That particular code block IMHO is why rust is going to have a hard time truly gaining widespread usage. Even as someone somewhat familiar with rust, moving the example into a program, and modifying it in fairly trivial ways took me the better part of a day.
    - Rusky 6y ago
      > Even if your pretty familiar with rust you still have to break it apart and explicitly place the types in the "Let" statements to know the intermediate types in order to look up the method documentation. Maybe this is just me misreading your phrasing, but why would you actually have to break it apart into `let` statements? You can look up the types without modifying the program. Or are you talking about asking the compiler for the types with the `let _: () = ...` (or similar) trick? At that point you can just ask an IDE, also without modifying the program.
    - steveklabnik 6y ago
      What’s the syntax error? I’m not a Linux user and there’s two different examples, but I am curious! Most code samples get automatically tested, but READMEs currently do not.
- fluffything 6y ago
  `auto` is just a keyword, that's used in D and C++ to implement many many different language features. Rust does not have fn foo() -> let { ... } where fn foo() -> let { 0_i32 } let x: i32 = foo(); fn bar() -> let { 0_f32 } let y: f32 = bar(); That is, you can't have an opaque function return type, that's both opaque, but simultaneously the user can name and use all interfaces from. If you change the implementation of `bar` with such a feature to return `i32` instead, all calling code of `bar` would break. And that's precisely why Rust doesn't have D/C++'s `auto` in return position.
schveiguy 6y ago
This wouldn't work for D. D doesn't constrain return types to something less than what they are. A Range is not just an Iterator, it has optional pieces that depend completely on the given type. For example, the return of map could provide indexing, or it could provide forward and backward iteration, or it might have methods that are completely unrelated to the type. There is no good reasonable and non-confusing way to describe all the things map could return depending on the input. It's much better to just describe it conceptually in the human-readable docs, and let the person understand the result. I'll note that just above the function map in D's source is the documentation. You just need a little more context, and it will describe what map returns in a much more (IMO) useful fashion than a return type that might be several lines long and consist of various static conditionals: "The call map!(fun)(range) returns a range of which elements are obtained by applying fun(a) left to right for all elements a in range." This is the difference between duck typing and generics.
- the8472 6y ago
  In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation. https://doc.rust-lang.org/std/vec/struct.Vec.html#implementations https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...
  - gmueckl 6y ago
    This looks insane, mostly because there must be some repeated code in all these impls. The D way of solving this is to statically query the properties of the passed in type at compile time whenever a part of the template needs to be specialized. It can make for very concise code, but you can't name the exact input type with this approach.
  - schveiguy 6y ago
    What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work, so I just gave up and wrote multiple functions without generics. I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.
TwoBit 6y ago
? both are the same.
arunc 6y ago
OP's point was about auto being littered in documentation and not in the code itself. Having auto is a boon for certain design aspects. As system level programming language D offers everything in betterC mode. Of course it can offer more. But a small community can do only so much.
- aldacron 6y ago
  It's not "littered" in the documentation for anyone who understands the basics of D's ranges. auto is the correct choice here. Range functions are lazy, meaning they are almost always used in a chain of function calls that ends in something like `.array` to get a concrete type -- an array in this case. At no point in that process do you care about the actual return type of any of those functions.

EvenThisAcronym 6y ago

Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.

kibwen 6y ago
That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)
- StillBored 6y ago
  Which helps out the documentation side, but destroys code readability. Particularly since rust users appear to really like creating long method call chains, frequently with a closure or two sprinkled in. Take this "example" https://github.com/diwic/dbus-rs#server https://github.com/diwic/dbus-rs#server. For a beginning user of the library that is nearly impenetrable without breaking each of those calls apart. Even if your pretty familiar with rust you still have to break it apart and explicitly place the types in the "Let" statements to know the intermediate types in order to look up the method documentation. This style of coding is so bad, that it turns out the example has a syntax error. Good luck finding it without the compiler or a quality editor though. Worse, the example doesn't actually work due to further bugs. Anyway, rust by itself may be ok. Some of the core concepts are good, but the way people are using it is leading to inpenteratble messes of code. Code like the above combined with what seems excessive/unnecessary use of generics create problems for more advanced usage when it comes to learning and modifying a piece of code. Some people have blamed this on the language's learning curve, but I'm not sure that is appropriate. By itself the language is fairly straightforward, the difficulties occur when people are working around the language and pile in masses of write only code. That particular code block IMHO is why rust is going to have a hard time truly gaining widespread usage. Even as someone somewhat familiar with rust, moving the example into a program, and modifying it in fairly trivial ways took me the better part of a day.
  - Rusky 6y ago
    > Even if your pretty familiar with rust you still have to break it apart and explicitly place the types in the "Let" statements to know the intermediate types in order to look up the method documentation. Maybe this is just me misreading your phrasing, but why would you actually have to break it apart into `let` statements? You can look up the types without modifying the program. Or are you talking about asking the compiler for the types with the `let _: () = ...` (or similar) trick? At that point you can just ask an IDE, also without modifying the program.
  - steveklabnik 6y ago
    What’s the syntax error? I’m not a Linux user and there’s two different examples, but I am curious! Most code samples get automatically tested, but READMEs currently do not.
fluffything 6y ago
`auto` is just a keyword, that's used in D and C++ to implement many many different language features. Rust does not have fn foo() -> let { ... } where fn foo() -> let { 0_i32 } let x: i32 = foo(); fn bar() -> let { 0_f32 } let y: f32 = bar(); That is, you can't have an opaque function return type, that's both opaque, but simultaneously the user can name and use all interfaces from. If you change the implementation of `bar` with such a feature to return `i32` instead, all calling code of `bar` would break. And that's precisely why Rust doesn't have D/C++'s `auto` in return position.

schveiguy 6y ago

This wouldn't work for D. D doesn't constrain return types to something less than what they are. A Range is not just an Iterator, it has optional pieces that depend completely on the given type. For example, the return of map could provide indexing, or it could provide forward and backward iteration, or it might have methods that are completely unrelated to the type. There is no good reasonable and non-confusing way to describe all the things map could return depending on the input. It's much better to just describe it conceptually in the human-readable docs, and let the person understand the result. I'll note that just above the function map in D's source is the documentation. You just need a little more context, and it will describe what map returns in a much more (IMO) useful fashion than a return type that might be several lines long and consist of various static conditionals: "The call map!(fun)(range) returns a range of which elements are obtained by applying fun(a) left to right for all elements a in range." This is the difference between duck typing and generics.

the8472 6y ago
In rust this would be expressed as multiple impl blocks with different generic parameters which show up as such in the documentation. https://doc.rust-lang.org/std/vec/struct.Vec.html#implementations https://doc.rust-lang.org/std/vec/struct.Vec.html#implementa...
- gmueckl 6y ago
  This looks insane, mostly because there must be some repeated code in all these impls. The D way of solving this is to statically query the properties of the passed in type at compile time whenever a part of the template needs to be specialized. It can make for very concise code, but you can't name the exact input type with this approach.
- schveiguy 6y ago
  What am I looking at there? Are those all traits on Vec that I then have to parse mentally so I can understand what I can do with it? Are all those pages basically to say "Vec works like an array of T"? I've dealt with generics in other languages such as Swift and C#, and they were substandard to D's templates IMO. I remember in C#, I could not get a simple generic function that accepted both a string and Int to work, so I just gave up and wrote multiple functions without generics. I'm sure some people find this documentation helpful, but it doesn't look as useful to me as map's simple one-liner.

TwoBit 6y ago

? both are the same.

arunc 6y ago

OP's point was about auto being littered in documentation and not in the code itself. Having auto is a boon for certain design aspects. As system level programming language D offers everything in betterC mode. Of course it can offer more. But a small community can do only so much.

aldacron 6y ago
It's not "littered" in the documentation for anyone who understands the basics of D's ranges. auto is the correct choice here. Range functions are lazy, meaning they are almost always used in a chain of function calls that ends in something like `.array` to get a concrete type -- an array in this case. At no point in that process do you care about the actual return type of any of those functions.