[cm2187]

Usually a new version of VS comes with a new version of the .net framework. It doesn't seem to be the case here. I can't see the tuples announced for VB for instance.

I am getting an error with Dim p As (x As Integer, y As Integer) saying that I am missing a reference to 'System.Runtime.CompilerServices.TupleElementNamesAttribute' (but if tuples are part of the language why do I need an external reference? and this assembly doesn't seem to exist anyway). In fact right now a simple empty command line program containing nothing more than the below hangs the VS IDE completely...

  Module Module1

    Sub Main()
        Dim p As (x As Integer, y As Integer)
    End Sub

  End Module

[louthy]

I can't comment for VB or the error you're getting, but System.ValueTuple is a nu-get package that facilitates the new tuples in C#; so maybe try including that in your project?

[cm2187]

But how can it be called a new language feature if it's not supported unless I add some external references (and the what's new page doesn't make any reference to a nuget package).

[Metasyntactic]

Hi CM, i'm Cyrus, a developer on the C#/VB IDE.

First: The benefit of this approach is that people can now use this sort of feature down-level. i.e. you can interoperate with this code even if you're on a previous version of C# or VB. Also, it means that the libraries can be rev'ed independently of compiler and IDE releases. There's a lot of value in having this sort of thing. And in the past people would rightfully complain about the lockstep nature of wanting to adopt a language feature, but having to switch over an entire toolchain to do so.

Second: We actually do have a feature to help you out here. It's available in C# in RTM and will be in VB in the next update. If you enable: Tools | Options | Text Editor | (C#/VB) | Advanced | 'Suggest usings for types in NuGet packages'

then we'll offer to add the NuGet package for this for you when you use a tuple.

We'd like to eventually make this option on by default. However, there is a memory cost to it, and we'll need to win back that memory usage in some way so that we can abide by our commitment to VS using less memory and being more lightweight by default than previous versions.

[cm2187]

But, to repeat another comment I made below, are you satisfied with this solution? Would you expect to have to go to a package manager to use tuples in python? The power of .net, and of visual basic in particular was its simplicity. What I am seing is Microsoft going into the opposite direction, with an ever more fractured ecosystem, .net, .net core, .net portable and .net standard running in parallel. Asp.net and asp.net core running in parallel, winform, wpf, winRT apps, uwapps, xamarin, etc running in parallel. And now when a new feature is introduced in the syntax it requires to add some external dependencies, which can be simplified by changing some default deep into the IDE...

My opinion is that simplicity matters a lot to the success of a platform. And by the way nothing in the error that you display when using tuples in VS2017 suggests a nuget package or an assembly name that can be searched.

[Metasyntactic]

> are you satisfied with this solution?

Yes. This approach allows for far more interoperability in this space. Instead of having language features be locked into specific compilers/toolsets. You mentioned 'simplicity' and we've traded off one sort of simplicity for another. The approach you would like (which we used in the past) used to not be simple for the customer that wanted the scenarios to work that we're enabling now.

> Would you expect to have to go to a package manager to use tuples in python?

I could definitely expect that new language features might require library updates, yes.

> My opinion is that simplicity matters a lot to the success of a platform.

I think a lot of things matter to the success of a platform. For every developer who wants the type of simplicity you mention, there are developers who want other sorts of things to be simple.

> And by the way nothing in the error that you display when using tuples in VS2017 suggests a nuget package or an assembly name that can be searched.

Yes. We could certainly make this experience better, and that's on me. However, as i mentioned already, there were difficult constraints to balance. We're hoping that our work moving things Out-Of-Process will help make it so that we can just light up this scenario by default. Then, you'd get this error, and the lightbulb would be right there to fix it up.

However, like with all things in development, you can't always get everything you want complete for every release. In this case we did not feel like it was justified to hold back all the rest of great feature work and performance improvements in VS just because users would have to do one manual step with one language feature when working with C#. You are free to disagree with that assessment on our part. But we're always going to end up having to pick a set of things we don't think will make it into any given release, and it's quite likely that for any given release there will be some things that you'd want (and which would make things better) that won't make it.

A great benefit of the new VS is that it's now much simpler for us to ship updates very rapidly. Instead of needing to wait literally years for updates, we can patch things immediately and we can complete features and get them in the hands of users in a matter of weeks. In that regard, i'm ok if this one particular experience isn't perfect. We can improve things as we move forward and continue delivering better and better experiences.

Thanks!

[cm2187]

Actually I tried using that nuget package on VS2015 but it doesn't seem to work. Is VS2015 support C# only?

[louthy]

The type is library code, the only part that's a language feature is the grammar. ValueTuple is a type like any other, and the CLR will need it referenced to use it.

[cm2187]

Microsoft seriously needs to rediscover the value of simplicity. I don't need to install some third party library to use tuples in python. Tuples being part of the language means it just works.

[recursive]

Well I mean, it's not 3rd party. It's a 1st party library.

[cm2187]

My point is that it's not even an assembly which is part of the installed .net framework. It's an assembly that needs to be downloaded from the internet. That's not exactly the syntax of the language nor a model of simplicity... Again compare it to python.