3 ms·

As for fields and other class-level type declarations not using type inference, I guess that's a very conscious decision, considering that those constitute an A

by ygra 11y ago

As for fields and other class-level type declarations not using type inference, I guess that's a very conscious decision, considering that those constitute an API, which should be carefully changed, if at all. Just having a method return type silently change when you change something in the method body sounds a bit off to me in that context.

MichaelGG 11y ago
I don't think so. Eric Lippert says its due to internal compiler limitations[1]. Though now that they rewrote the compiler and haven't fixed it, who knows. Rust (incorrectly) deliberately requires type annotations for top-level items in the name of clarity. (Which ironically, makes it more difficult for beginners as they now have to make sure they got the type syntax correct just to write functions. Plus it adds visual noise that should be up to the programmer.) As for things changing with type inference... if you run into that problem then add annotations. I'd be surprised if things continue to build after changing e.g. return types. I'd imagine this would only really be a problem with types that have implicit conversions (yet another reason to not have implicit conversions.) 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
- Locke1689 11y ago
  Eric is wrong.[1] We could change it, we're choosing not to and I vehemently disagree with those who think we should change it. [1] Well, he was right when he wrote that, but he's wrong now.
  - MichaelGG 11y ago
    Well, that's disappointing. It'd be nice if C# allowed more succinctness, and eliding type annotations is a major part of that. It feels like those aspects of C# were chosen just to implement LINQ, then forgotten. Also don't mistake my tone in my comments. While I am annoyed with the direction MS is taking, C# is still obviously better than most languages and the tooling is a fantastic. I'm happy it is still being improved, despite detractors saying it's too kitchen-sinky or changing too fast.
- kibwen 11y ago
  I doubt your experience with Rust if you refer to its decision to opt for function-local type inference as "incorrect". Whole-program type inference works for scripts, but for programming in the large it's sheer horror. I want my functions to provide certain contracts, and I don't want to have to read the function body to ensure those contracts are upheld (and neither does the typechecker). Typed function signatures keep errors local and are the feature that keeps implicit return values from becoming a footgun.
  - MichaelGG 11y ago
    Most of my experience is with F#, but I've simply not found it to be a problem. At module boundaries, I'm free to annotate as much as I want. The point is that it's up to me to decide what I need. I'd be surprised to find many cases where return types change around and the program still compiles but is now incorrect. Ideally, items and expressions would have the same syntax and usability. I find in F#, I just start writing a long function with lots of nesting, then copy pieces out to refactor as needed.

by ygra 11y ago

MichaelGG 11y ago

I don't think so. Eric Lippert says its due to internal compiler limitations[1]. Though now that they rewrote the compiler and haven't fixed it, who knows. Rust (incorrectly) deliberately requires type annotations for top-level items in the name of clarity. (Which ironically, makes it more difficult for beginners as they now have to make sure they got the type syntax correct just to write functions. Plus it adds visual noise that should be up to the programmer.) As for things changing with type inference... if you run into that problem then add annotations. I'd be surprised if things continue to build after changing e.g. return types. I'd imagine this would only really be a problem with types that have implicit conversions (yet another reason to not have implicit conversions.) 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...

Locke1689 11y ago
Eric is wrong.[1] We could change it, we're choosing not to and I vehemently disagree with those who think we should change it. [1] Well, he was right when he wrote that, but he's wrong now.
- MichaelGG 11y ago
  Well, that's disappointing. It'd be nice if C# allowed more succinctness, and eliding type annotations is a major part of that. It feels like those aspects of C# were chosen just to implement LINQ, then forgotten. Also don't mistake my tone in my comments. While I am annoyed with the direction MS is taking, C# is still obviously better than most languages and the tooling is a fantastic. I'm happy it is still being improved, despite detractors saying it's too kitchen-sinky or changing too fast.
kibwen 11y ago
I doubt your experience with Rust if you refer to its decision to opt for function-local type inference as "incorrect". Whole-program type inference works for scripts, but for programming in the large it's sheer horror. I want my functions to provide certain contracts, and I don't want to have to read the function body to ensure those contracts are upheld (and neither does the typechecker). Typed function signatures keep errors local and are the feature that keeps implicit return values from becoming a footgun.
- MichaelGG 11y ago
  Most of my experience is with F#, but I've simply not found it to be a problem. At module boundaries, I'm free to annotate as much as I want. The point is that it's up to me to decide what I need. I'd be surprised to find many cases where return types change around and the program still compiles but is now incorrect. Ideally, items and expressions would have the same syntax and usability. I find in F#, I just start writing a long function with lots of nesting, then copy pieces out to refactor as needed.