C# 6.0 Feature: using static #9
Conversation
BillWagner
force-pushed
the
feature-using-static
branch
2 times, most recently
from
63a4c98 to
80bb520
Compare
BillWagner
force-pushed
the
feature-using-static
branch
from
80bb520 to
6e691c6
Compare
Current spec text for using static proofread fixes
I chose to use non-descript names rather than provide an example from the class library. I think that's sufficient to understand, and doesn't beg more questions about the design decision (even in an informative example).
BillWagner
force-pushed
the
feature-using-static
branch
from
c5ce449 to
2066313
Compare
Co-authored-by: Jon Skeet <skeet@pobox.com>
I wanted to check other clauses in the standard to compare. Jon is correct.
|
Meeting is happy to merge when formatting is sorted. |
Make the following changes to the code samples in this clause: - Add a blank line between peer elements *except* for multiple `using` directives and multiple `alias` directives. (I did add a blank line between `using` and `alias` directives. - Use Allman brace style on non-empty `class` declarations. (I'd prefer using Allman brace style on methods, but the standard currently uses K&R style for methods consistently.
There was a problem hiding this comment.
@jskeet I tried to make the changes in this clause to develop our general practice.
I followed the notes from the meeting, and then applied my own opinion on whitespace, because I was doing the work. 😀
| @@ -669,7 +713,9 @@ Using this notation, the meaning of a *qualified_alias_member* is determined as | |||
| > *Note*: The identifier `global` has special meaning only when used as the left-hand identifier of a *qualified_alias_name*. It is not a keyword and it is not itself an alias; it is a contextual keyword ([§7.4.4](lexical-structure.md#744-keywords)). In the code: | |||
| > ```csharp | |||
| > class A { } | |||
| > class C { | |||
| > | |||
| > class C | |||
There was a problem hiding this comment.
This was one of 2 instances for K&R braces on class declarations. That's why I changed this one.
| > class C { | ||
| > | ||
| > class C | ||
| > { |
There was a problem hiding this comment.
second instance of K&R braces on a class
| @@ -166,6 +167,7 @@ Within global attributes and member declarations in a compilation unit or namesp | |||
| > namespace N3 | |||
| > { | |||
| > using A = N1.N2.A; | |||
| > | |||
There was a problem hiding this comment.
@jskeet This was one type of change I wanted to check on. I think it's better by having the blank line, but it's a very mild preferences.
For our "coding style", I'd like to say different elements should have a blank line between them. On the other hand, I like a rule that doesn't add a blank line where the element is an empty class or namespace.
See also line 179, 192, 201-203.
There was a problem hiding this comment.
Mmm, interesting. I probably wouldn't have added blank lines in 179, 192, 201-203... but I'm quite happy for us to do so, and that should probably be the default. We should just allow ourselves to have an exception for things like:
public void M(int x) {}
public void M(string y) {}
public void M(int x, string y = null) {}... in an example about overload resolution, for example.
There was a problem hiding this comment.
I agree. I think that's easily handled by adding methods to my exception in the previous comment.
There was a problem hiding this comment.
I opened #358 to start the coding standard discussion.
I'll merge this.
PR #9 has been merged, so this is done now.
PR #9 has been merged, so this is done now.
Current spec text for using static.
Creating a draft PR because of outstanding TODO item.TODO item is complete.Fixes #51
Fixes #199