6 ms·

Hey there, C# language designer here. > Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same releas

Hey there, C# language designer here. > Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release. Out variables are really great when working with existing code that predates Tuples (for example, the entire BCL). We don't just introduce language features that will only work well for new code. We also want to make the experience of coding against existing APIs feel better. > Ref returns and locals look like a source of constant headaches. That 'headache' has to be weighed against the needs of some parties to write very fast code and to have as little overhead as possible. ref returns enables a much more pleasant coding experience that enables these sorts of speedups in these specialized scenarios. > It's much harder to reason with code when the data can be modified by random others bits of code. There is a simple solution to this of course, don't expose your data through ref returns :) For many (likely most) developers, ref returns simply won't be something that ever hits their radar. Similar to stackallocs and other esoteric features, this is really a targeted improvement for people who really like working in .Net but are finding it hard to squeeze out essential perf in some core scenarios. The .net runtime supports this features fantastically. We wanted to make it available to people who like the power and safety of C#, but occasionally need some low level hooks to get that extra perf boost as well.

int_19h 10y ago
Did you guys look into alternative syntax for return types? It really is a huge eyesore, and impediment to reading, when you have more than just a typename and a couple of modifiers like * and [] attached to it. With tuples especially, it's even worse, because the method name gets squished between two very similarly looking ()s, which is very different from how methods have historically looked in code. If I were scanning code fast, I'm not sure I would even read it as a function declaration. C++ adopted its "auto ... -> ..." syntax a while ago - granted, they had a forcing function in form of decltype(), but many people also use it for readability reasons with complex return types. I hope C# follows suit; or, better yet, comes up with a unified type-after-name syntax a la ES6, that can be used everywhere in the language, while retaining existing syntax for back-compat purposes.
- macca321 10y ago
  What would you suggest? public TResult SomeMethod() where TResult : (string name, int id)
  - int_19h 10y ago
    The most obvious approach would be to repurpose C++ syntax, since it's already been around for a while, and C# syntax is generally pretty close to C++ in many respects. So: public SomeMethod(bool b) -> (string name, int id) { ... } However, this may be undesirable due to confusion with => for lambdas and expression-bodied methods, especially in: public SomeMethod(bool b) -> (string name, int id) => ... : is the next obvious candidate, and would unify the syntax with TypeScript and many other languages. But given that it's already used for labels and named arguments, I'm not sure there's enough room there to reuse it also for types. :: is another decent choice in terms of familiarity coming from other languages (Fortran, Haskell etc). But, unfortunately, it's already taken for extern alias, and I don't think this could be easily disambiguated in many contexts. Now, if this is narrowly scoped to method return type only (i.e. we're not trying to invent a syntax that could later be used in a similar way to swap the type and the name in other places, like arguments and variables), and only as a fallback for when the usual "Type Name" arrangement has poor readability, perhaps take a hint from Ada and reuse "return"? public SomeMethod(bool b) return (string name, int id) { ... } A tad verbose, but if it's intended to be used sparingly, primarily with tuple-returning methods and deeply nested generics, I think that's okay - tuples themselves are pretty verbose when components are named. Or maybe borrow "as" from VB? It looks like it could be extended to other kinds of declarations in the future in a straightforward manner, without conflicting with its existing use for casts: // Just for method return types public SomeMethod(bool b) as (string name, int id) { ... } // For everything public SomeMethod(b as bool) as (name as string, id as int) { var x as float; TryFoo(out var y as bool); ... switch (obj) { case foo as Foo: ... } }
    - flukus 10y ago
      I like the as syntax, it may conflict with casting though when used on variables. public SomeMethod(bool b) -> (string name, int id) { ... } When was this added to c++? I think I need to brush up on my lower level skills.
dexwiz 10y ago
Adding features for the the subset of developers that need optional performance enhancements is great. However, it does seem ripe for misuse. As in the developer who makes everything a ref reference because they read it makes it "faster." Would there be a way to get Visual Studio to warn about this?
- cjalmeida 10y ago
  Not .NET developer here but the usual way is to use some sort of linting tool to "disable" the esoteric features.
  - flukus 10y ago
    These tend to become cargo cult practices, "thou shalt never" that get in the way of those few places where they are useful.
    - snaky 10y ago
      I don't think so. The purpose of compiler warnings, lint-like tools, static analyzers and such is to bring developer attention to some block of code. Not 'Hey, you should not do it this way', but 'Hey, is this thing here as intended by you or just a typo or mistake?'. I like the way its implemented in Perl. Use 'use strict' by default, and guard the block where you really need something unusual by 'no strict something' - refs, vars, subs - so neither compiler nor people reading your code never being confused whether is it a mistake or author's intention.
      - cema 10y ago
        In C# one can always #pragma warning disable ${list of warnings} and #pragma warning restore ${list of warnings} https://msdn.microsoft.com/en-us/library/441722ys.aspx https://msdn.microsoft.com/en-us/library/441722ys.aspx Although frankly the list of warnings to disable and restore consists of warning numbers, not names, which is not super convenient.
- CyrusNajmabadi 10y ago
flukus 10y ago
> That 'headache' has to be weighed against the needs of some parties to write very fast code and to have as little overhead as possible. ref returns enables a much more pleasant coding experience that enables these sorts of speedups in these specialized scenarios. I'm worried this could result in a loss of focus, you can't make everyone happy all the time. c# is a fantastic language to develop applications in (web or desktop) but it's never going to be the fastest language around or be a systems level language. For me some of the other features listed here (like immutable records) would be a much better fit for where c# excels already.
- pjmlp 10y ago
  The Midori project proved otherwise. One of the reasons we are stuck with C and C++ is because other language vendors, including Microsoft, dropped the ball regarding performance of type safe languages. Do you think C++ would have been kept around if Java and the CLR had been AOT compiled to native code with focus on compiler optimisations since day one? I really appreciate the efforts of the .NET team in adopting the Midori lessons in the standard .NET stack.
  - int_19h 10y ago
    Some things can be rather tricky to AOT-compile, especially when you don't have a fixed "world" (i.e. when code can be dynamically loaded, as is the case with both Java classes and CLR assemblies). Consider virtual generic methods, for example. If your set of types is not statically bound, you can't allocate the appropriate number of vtable slots in advance, because you don't know all the instantiations.
    - pjmlp 10y ago
      C++ has the same problem. I was already using dlls with plugins in Windows 3.1 and C++.
      - int_19h 10y ago
        C++ doesn't have this problem, because it doesn't allow virtual function templates. For that matter, it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template) - and then only for those explicit instantiations. So it is effectively impossible to have a generic C++ API using templates that is not statically linked.
zamalek 10y ago
Honestly, I'd like to have seen ref returns implemented as attributed out params (syntactic sugar). As it stands I can't see me using them in any of places that I originally planned to - I am exactly the target market for that feature. Still, I'm sure something interesting can be done with this.
16bytes 10y ago
> Out variables are really great when working with existing code that predates Tuples (for example, the entire BCL). We don't just introduce language features that will only work well for new code. We also want to make the experience of coding against existing APIs feel better. I disagree on this point. If there is a language feature that has been superseded by a better alternative, continuing to add sugar to the old feature only serves to perpetuate its use. It embiggens the language while providing relatively little value in return. Furthermore, it adds confusion as to what should be considered idiomatic. Tuples and deconstruction are so clearly better than out variables, I would have thought it would make more sense to deprecate the "out" feature entirely. Or, at the very least, not make it easier to use them. Awkward and outdated features should be painful to use. I also felt that this was a very odd addition. Even odder, the article doesn't even list tuples and deconstruction first.

int_19h 10y ago

Did you guys look into alternative syntax for return types? It really is a huge eyesore, and impediment to reading, when you have more than just a typename and a couple of modifiers like * and [] attached to it. With tuples especially, it's even worse, because the method name gets squished between two very similarly looking ()s, which is very different from how methods have historically looked in code. If I were scanning code fast, I'm not sure I would even read it as a function declaration. C++ adopted its "auto ... -> ..." syntax a while ago - granted, they had a forcing function in form of decltype(), but many people also use it for readability reasons with complex return types. I hope C# follows suit; or, better yet, comes up with a unified type-after-name syntax a la ES6, that can be used everywhere in the language, while retaining existing syntax for back-compat purposes.

macca321 10y ago
What would you suggest? public TResult SomeMethod() where TResult : (string name, int id)
- int_19h 10y ago
  The most obvious approach would be to repurpose C++ syntax, since it's already been around for a while, and C# syntax is generally pretty close to C++ in many respects. So: public SomeMethod(bool b) -> (string name, int id) { ... } However, this may be undesirable due to confusion with => for lambdas and expression-bodied methods, especially in: public SomeMethod(bool b) -> (string name, int id) => ... : is the next obvious candidate, and would unify the syntax with TypeScript and many other languages. But given that it's already used for labels and named arguments, I'm not sure there's enough room there to reuse it also for types. :: is another decent choice in terms of familiarity coming from other languages (Fortran, Haskell etc). But, unfortunately, it's already taken for extern alias, and I don't think this could be easily disambiguated in many contexts. Now, if this is narrowly scoped to method return type only (i.e. we're not trying to invent a syntax that could later be used in a similar way to swap the type and the name in other places, like arguments and variables), and only as a fallback for when the usual "Type Name" arrangement has poor readability, perhaps take a hint from Ada and reuse "return"? public SomeMethod(bool b) return (string name, int id) { ... } A tad verbose, but if it's intended to be used sparingly, primarily with tuple-returning methods and deeply nested generics, I think that's okay - tuples themselves are pretty verbose when components are named. Or maybe borrow "as" from VB? It looks like it could be extended to other kinds of declarations in the future in a straightforward manner, without conflicting with its existing use for casts: // Just for method return types public SomeMethod(bool b) as (string name, int id) { ... } // For everything public SomeMethod(b as bool) as (name as string, id as int) { var x as float; TryFoo(out var y as bool); ... switch (obj) { case foo as Foo: ... } }
  - flukus 10y ago
    I like the as syntax, it may conflict with casting though when used on variables. public SomeMethod(bool b) -> (string name, int id) { ... } When was this added to c++? I think I need to brush up on my lower level skills.

dexwiz 10y ago

Adding features for the the subset of developers that need optional performance enhancements is great. However, it does seem ripe for misuse. As in the developer who makes everything a ref reference because they read it makes it "faster." Would there be a way to get Visual Studio to warn about this?

cjalmeida 10y ago
Not .NET developer here but the usual way is to use some sort of linting tool to "disable" the esoteric features.
- flukus 10y ago
  These tend to become cargo cult practices, "thou shalt never" that get in the way of those few places where they are useful.
  - snaky 10y ago
    I don't think so. The purpose of compiler warnings, lint-like tools, static analyzers and such is to bring developer attention to some block of code. Not 'Hey, you should not do it this way', but 'Hey, is this thing here as intended by you or just a typo or mistake?'. I like the way its implemented in Perl. Use 'use strict' by default, and guard the block where you really need something unusual by 'no strict something' - refs, vars, subs - so neither compiler nor people reading your code never being confused whether is it a mistake or author's intention.
    - cema 10y ago
      In C# one can always #pragma warning disable ${list of warnings} and #pragma warning restore ${list of warnings} https://msdn.microsoft.com/en-us/library/441722ys.aspx https://msdn.microsoft.com/en-us/library/441722ys.aspx Although frankly the list of warnings to disable and restore consists of warning numbers, not names, which is not super convenient.
CyrusNajmabadi 10y ago

flukus 10y ago

> That 'headache' has to be weighed against the needs of some parties to write very fast code and to have as little overhead as possible. ref returns enables a much more pleasant coding experience that enables these sorts of speedups in these specialized scenarios. I'm worried this could result in a loss of focus, you can't make everyone happy all the time. c# is a fantastic language to develop applications in (web or desktop) but it's never going to be the fastest language around or be a systems level language. For me some of the other features listed here (like immutable records) would be a much better fit for where c# excels already.

pjmlp 10y ago
The Midori project proved otherwise. One of the reasons we are stuck with C and C++ is because other language vendors, including Microsoft, dropped the ball regarding performance of type safe languages. Do you think C++ would have been kept around if Java and the CLR had been AOT compiled to native code with focus on compiler optimisations since day one? I really appreciate the efforts of the .NET team in adopting the Midori lessons in the standard .NET stack.
- int_19h 10y ago
  Some things can be rather tricky to AOT-compile, especially when you don't have a fixed "world" (i.e. when code can be dynamically loaded, as is the case with both Java classes and CLR assemblies). Consider virtual generic methods, for example. If your set of types is not statically bound, you can't allocate the appropriate number of vtable slots in advance, because you don't know all the instantiations.
  - pjmlp 10y ago
    C++ has the same problem. I was already using dlls with plugins in Windows 3.1 and C++.
    - int_19h 10y ago
      C++ doesn't have this problem, because it doesn't allow virtual function templates. For that matter, it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template) - and then only for those explicit instantiations. So it is effectively impossible to have a generic C++ API using templates that is not statically linked.

zamalek 10y ago

Honestly, I'd like to have seen ref returns implemented as attributed out params (syntactic sugar). As it stands I can't see me using them in any of places that I originally planned to - I am exactly the target market for that feature. Still, I'm sure something interesting can be done with this.

16bytes 10y ago

> Out variables are really great when working with existing code that predates Tuples (for example, the entire BCL). We don't just introduce language features that will only work well for new code. We also want to make the experience of coding against existing APIs feel better. I disagree on this point. If there is a language feature that has been superseded by a better alternative, continuing to add sugar to the old feature only serves to perpetuate its use. It embiggens the language while providing relatively little value in return. Furthermore, it adds confusion as to what should be considered idiomatic. Tuples and deconstruction are so clearly better than out variables, I would have thought it would make more sense to deprecate the "out" feature entirely. Or, at the very least, not make it easier to use them. Awkward and outdated features should be painful to use. I also felt that this was a very odd addition. Even odder, the article doesn't even list tuples and deconstruction first.