I actually like the proposal less now with the amendments. This is primarily due to the Alternatives considered section now having references to off hand suggestions from people in this thread that haven't been fully discussed and explored but the proposal dismisses them entirely.
The additional examples also make me realise that this won't just be used in a few places, but could be used everywhere which will clutter the language into an ugly mess. Granted my opinion is subjective rather than objective, but for this proposal its something I feel quite strongly about. I don't want to constantly wonder if something required back-ticks or not (as demonstrated in the case examples), I just want to use a predictable language that is all accessible in the same consistent manner.
The proposal is too big of a hammer for this nail. I agree with the above statements by Douglas. I don’t think the usecases warrant a chance in swift.
I would be more in favor of a smaller hammer that would introduce a matrix of supported cases that we can then as a community agree upon. One usecase that is important to me is identifies that start with numbers.
That's not a fair characterization, in my opinion. The additions that the author made to Alternatives Considered and Future Directions—a @test attribute, discussion of Unicode normalization, and a possible way of escaping backticks in a backtick-escaped identifier, the effects on a future runtime type lookup API—were all discussed in the original pitch thread and weren't just off-hand suggestions that came up during the review.
As a meta discussion point, this is unfortunately an example of the concern I had in my review of this proposal up-thread. I wish the original proposal text had captured the good amount of discussion in the pitch thread that fleshed out more details and additional motivating use cases so that it would be (IMO) a more accurate representation of what the proposed change is.
There have been a number of reviewers in this thread who have said that the proposal's "only motivating use case" was for test naming. While I don't agree that's the case and mentioned others from the pitch thread in my own review, I also can't disagree that that's a valid takeaway from a proposal review standpoint for someone who didn't follow the pitch thread, because what they're reviewing is the proposal text that was posted here, not all of the preceding context/discussion.
As it stands, the proposal permits too many new kinds of characters for escaped identifiers for me to +1 it.
-1
I find this point debatable.
Yes, this proposal fits the feel and direction of Swift, however poorly. It does outline and address some apparent deficiencies that restrict identifier naming, e.g. naming enum cases like .200.
Never have I ever used a programming language that permits whitespace in identifiers.
I read the proposal and followed the discussion in this thread.
The review of SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers ran from January 13 through January 20. The core team has decided to reject this proposal. Community reaction was mixed, and many of the people both supporting and rejecting the idea had concerns about the breadth of the set of characters this allows. Allowing more characters in identifiers would also add complexity to tooling, including syntax highlighting, IDEs, and runtime reflection libraries, which would need to be able to recognize quoted identifiers, know when identifiers would need to be quoted for presentation purposes, and potentially need to implement more elaborate parsing and escaping rules to handle these generalized identifiers. In the core team's judgment, this added demand on tooling is not justified by the amount of utility provided by the proposal. Of the use cases that came up in the pitch, proposal, and review discussion:
One proposed use was to allow test functions to have self-descriptive natural language names, as in func `test that two plus two equals four`() . The core team feels that this use case could be better handled by test library design that allowed strings to be associated with test cases, rather than try to encode that information entirely in symbol names.
This feature could also be used to enable libraries to more directly encode domain-specific names that are not currently valid Swift identifiers, such as status codes which begin with numbers like HTTPStatus.`404`, naming conventions that use normally-reserved symbols like SFSymbols.`10.circle`, or names from other languages Swift may interoperate with that have different valid identifier character sets like Forth.`FM/MOD`. This use case is more in line with the original intent of the backtick identifier feature, which was to allow for interop with libraries from C/ObjC/C++ that use names that would normally be reserved in Swift. However, the core team would like to see more concrete work done on libraries that would benefit from this functionality, to better gauge whether it is really essential or merely nice-to-have, and whether allowing a more restricted character set could achieve the desired results with less tooling complexity burden.
The proposal also offers the syntax Foo.`+` as a way to spell qualified references to operators. The core team believes this is an important gap in the language to fill. However, the backtick syntax in its current form is strongly associated with removing "magic" from keywords, and in association with operator tokens, there is a potential for confusion as to whether + is the same as the operator + or a regular identifier made to be named + . Furthermore, there are additional aspects of operator naming that need to be addressed in order to fully solve the problem; particularly, there would ideally be a way to disambiguate the prefix , postfix , and infix forms of an operator without relying on type context to do so. The core team thinks that the subject of operator references deserves a design exploration of its own, with its own pitch and proposal.
Thanks to @adellibovi for proposing and implementing this feature, and thanks to everybody who participated in the review!
I think Swift needs a broader strategy for improving tests. This change would have addressed one of the pain points (the desire for plain-English descriptions of tests), but not others, like:
Automated test discovery on platforms without an ObjC runtime
Parameterized tests, or more generally, procedurally generated tests. E.g. if you want to test 10 similar things, you can use a loop, but:
There's still only one test, so you can't rerun a single "run" of the loop body as its own independent test
Since there's only one test, a test failure doesn't tell you precisely which iteration of the loop failed.
There's no way to mark your own function to "act like a test helper function" ( like XCTAssertEqual(_:_:)).
Kinda hard to explain, but bear with me. When you call XCTAssertEqual with unequal arguments, Xcode shows the callsite of XCTAssertEqual as being the "problem spot", not the line of code inside of the implementation of XCTAssertEqual that actually raises the error/signal/whatever. Contrast that with your own functions. If you tried to make a helper function to simulate a parameterized test (you make N test cases, each calling this helper function with a different set of parameters, to emulate 1 test case with N parameter sets), and you hit a broken assertion, Xcode highlights the failing XCTAssert* within the helper's implementation. There's no way to get Xcode to treat the helper function opaquely like it does with XCTAssert*, to make it show the callsite as the "problem spot", rather than a part of its implementation.
I think these issues could be better addressed by rethinking how tests are implemented, through some combination of better reflection (that works across platforms), hygienic macros, or some other novel approach.
I think what you want here is to take file: StaticString = #file, line: UInt = #line arguments in the helper and forward them to calls to the underlying XCT methods. This will cause Xcode to report the error at the site of the call to the helper instead of inside the helper implementation.
+1
This would be great for naming tests. I’ve found that to be a great design in other languages. Allowing as many characters as possible could help with interoperability with other languages. I’m sure this would find use in storyboards were a more carefree style is acceptable.
Yes. This feels like a very safe uncontroversial change to the language. If we allow Emoji, we should allow for more advanced escaped identifiers!
Yes. This reminds me of testing frameworks I used years ago in Ruby on Rails. Ruby used a string closure pair, but function names make more sense for Swift. I thought it was a good idea then. It feels like a good idea for Swift too.
I read the short proposal. I have experience using unit testing systems with verbose test names. I think it would be a great fit for Swift.