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.
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.
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!
