SE-0308: `#if` for postfix member expressions

Evolution Proposal Reviews
1

The review of SE-0308, "#if for postfix member expressions, begins now and runs through April 16, 2021.

The proposal is authored by @rintaro.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

As always, thank you for your contribution to making Swift a better language.

More information about the Swift evolution process is available here.

Saleem Abdulrasool
Review Manager

33 Likes
2

+1

I don't love this syntactically for Swift, but I continuously attempt to do exactly this on a regular basis and expect it to work.
It's much more difficult to read code like this, but I feel the issue is actually because of incomplete editor support for showing the active path through the code as many IDEs do for other languages, and not because of a syntactical issue.

I would very much appreciate this functionality.

7 Likes
3

+1
looks very useful in DSL implementation in general and SwiftUI particularly. Writing cross platform SwiftUI views quite difficult without this feature and it creates hacks in code to implement something portable.

Main disadvantage of this addition for me is future difficulties in tooling for any IDE's except XCode

4

+1. #if is useful across platforms and this proposal makes it a lot easier to write cross-platform DSL.

We may need another #if for primary expressions some day. Looking forward to a more flexible #if syntax. This proposal provides a great template and takes a head start.

5

Instant yes.

I need this all the time when writing SwiftUI code and ended up making my own modifiers that simulate the #ifs and they are horrible. (Eg, they return either self or self.thingICannotCallOnADifferentOS())

6

+1.
Feels reasonable and proper evolution of the language.

@compnerd

Small typo at Line 166 Column 114:

you cannot [contiinue]
7

+1 from me. I honestly have no need for this right now, but if I were to need it I would expect it to work this way, and naïvely might get tripped up a few times by it. Definitely an improvement.

8

Definitely +1. I hit this all the time in making views that work in both iOS and macOS, pretty much identical to the examples within the proposal. Huge improvement

9

I'm highly in favor of this change. I don't think I would be on board with expanding to a full pre-processing language like we have in C because it really doesn't fit with Swift, but this is a good pragmatic compromise. This is the only limitation I run into with #if expressions.

10

Big +1

Currently writing cross platform SwiftUI is significantly more verbose and requires too much boilerplate code.

It looks a little weird admittedly but that’s a trade off worth making.

11

+1. This will make writing cross-platform SwiftUI code much more easier and make code easy to read and manage.

Until there's a better solution from the SwiftUI side, I support this proposal.

12

+1

To be sure: would it work for the following code ?

let description = defaultDescription
#if DEBUG
    + " " + debugDescription
#endif
1 Like
13

+1 I like this proposal. I think we run in to this situation too much in practice. I think there should also be greater effort to make modifiers cross-platform.

14

+1! I find these things ugly and they often make code hard to read, but I see no harm in this particular case.

15

I agree with others that this seems to be strictly an improvement that builds on what's already there, consistent with the current feel of Swift. It is reasonable for users to expect this to work, and I agree that it should work. I have given thoughtful consideration to the proposal as written.

It Would Be Nice (TM) if the same proposal would have been able to address binary operators (including as, etc.), because even though those aren't postfix member expressions, they are logically of-a-kind (particularly considering that .addingReportingOverflow(12) would be permitted but + 12 would not); at a minimum, the proposal should clarify that they aren't part of this proposal.

If would be not just nice, but essential, to ensure that the implementation preserves or improves the quality of diagnostics when users attempt to use #if in currently unsupported ways. As #if is supported in more and more places, it becomes more and more unusual (and, therefore, difficult for users to anticipate or understand the true underlying reason) when cryptic error messages come up in such circumstances (like the uncanny valley but for programming language grammar).

1 Like
16

As mentioned in Grammar changes section, starting #if body with binary operators such as '+' is not allowed in this proposal. This proposal focuses on postfix member expression.

I agree with @xwu supporting binary operators would be a nice improvement. But it needs different consideration and implementation from postfix member expressions. So I'd like to consider it as a future improvement after this proposal.

2 Likes