Skip to content
This repository was archived by the owner on Jun 21, 2023. It is now read-only.

Conversation

@Neme12
Copy link
Contributor

@Neme12 Neme12 commented Jun 17, 2018

No description provided.

Copy link
Contributor

@grokys grokys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Neme12 - this is a great idea. Should probably also be done for the projects in tests/ but they're in the middle of a refactor (#1721) anyway, so we can do that after the refactor.

@grokys grokys merged commit ee98b3b into github:master Jun 18, 2018
@Neme12 Neme12 deleted the langVersion branch June 18, 2018 10:10
Copy link
Collaborator

@jcansdale jcansdale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only reservation is that if/when we merge #1726, we'll be able to use VS 2017 exclusively for development and move to a higher language version.

If we do decide to require VS 2017, what language version do you think we should target?

@Neme12
Copy link
Contributor Author

Neme12 commented Jun 18, 2018

If we do decide to require VS 2017, what language version do you think we should target?

Is that a question for me? It depends on what version of VS 2017 you're happy mandating. Unless there's need for some of the ref or in features for performance somewhere, it's mostly just minor convenience features, so probably not a huge benefit.

That said, I've gotten quite used to some of them, for example non-trailing named arguments for clarity in C# 7.2:

M("argument", allowEmpty: true, cancellationToken) // as opposed to
M("argument", allowEmpty: true, cancellationToken: cancellationToken)

I think 7.2 would probably be a good compromise, it came out with 15.5 last year. 7.3 came out very recently with 15.7 (though I would definitely recommend everyone to update, the performance improvements are really awesome) and some tools like ReSharper might not support it yet.

@grokys
Copy link
Contributor

grokys commented Jun 18, 2018

I'm not sure why it's even a question to be honest ;) As you say, we should set it at the highest lang version that the version of VS we use supports. That version is probably going to be dictated by our CI.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants