SE-0330: Conditionals in Collections

A big -1 for this proposal. IMO the fact that #if in Swift is processed at syntax pass instead of lexical pass is a pain point to the compiler team in terms of maintenance, as well as a big surprise to programmers from the C language family.

If the #if should be processed at the lexical level (I think so), then patches like this proposal one after another are just hacky solutions to fix holes in the language. Not mentioning the additional test and potential compatibility cost when we finally make the shift.

If we think that #if should be processed at the syntax level (as it is today), then at least we could have a thorough discussion about all the pros and cons. This proposal is not urgent as far as I can see now.

This is a really great example. Note that (regardless of the shape of the final proposal) Swift doesn't (and can't) type check things in #if false regions. This means we can't know that the former is String to Int dictionary. The means that even the later can't work when FLAG is false, because we don't know the key/value types for the type of dictionary.

Trying to "make this work" in some cases would lead to a really fragile and unpredictable model that doesn't compose well.

One of the reasons that I'm in favor of a simple lexical #if model is that it is simple, explainable, and predictable for users. Our current model is already a pile of non-obvious special cases.

-Chris

2 Likes

Here is my take on the matter by way of "rerunning" some of the above examples using a lightweight syntax and bending some of the current rules a bit here and there:

let dictionary: [String: Int] = [
	#if flag {
		"foo": 10,
		"bar": 20
	}
]

let dictionary: [String: Int] = [] // allow this spelling when obvious to the compiler

let dictionary: [String: Int] = [
	#if flag1 {
		"foo": 10,
		"bar": 20
	}
	#if flag2 {
		// nothing here
	} else {
		"meep": 30,
		"yeex": 40
	}
]

let arr: B [
	#if flag {
		C()
	}
	B()
]

[
	value1,
	#if config {
		value2
	}
	value3
]

let dictionary: [String: Int] = [
	#if condition {
		"foo": 10,
		"bar": 20
	}
	if #available(iOS 14, *) {
		"baz": 10
	}
}

and no to:
let collection = [
#if flag {
"foo"
} else {
"foo": 12
}
]

to sum up:

  • a lightweight #if condition { ... } syntax vs more heavy current #if ... #endif syntax.
  • require explicit type annotation when it would be otherwise ambiguous or unclear - don't think it's a much of a burden.
  • relax some rules about punctuation to avoid visually disturbing commas
  • allow [ ] used instead of [:] when it is obvious to the compiler what's going on.
  • prohibit insane cases when type is changed between array and dictionary
  • and give #available the similar treatment (like in the last example)

It seems inevitable this proposal will be "returned for revision" to update the implementation and flesh out details of how various edge cases should be handled. I have tried over the last two days to build a toolchain of the original patch (as it can not easily be rebased) but this has eluded me so I can't give you anything more concrete to go on after all this time.

All of this is irrelevant however if a firm decision has already been made that the processing of preprocessor conditionals should be moved into the lexer which if this were the case, can this be communicated in the review decision and can someone be assigned to start looking at it please? In this way it can be made clear whether there is any point/need to pursue the proposal further.

1 Like

Since this would have considerable usability and compatibility impact on SwiftSyntax users like swift-format and others writing Swift source analysis tooling, I hope that such a proposed change would be given its own pitch/discussion thread and not be communicated as part of this review decision.

IMO, despite the limitations around where #if blocks can occur in the language, I think making them part of the syntax tree is still a strength of Swift's syntax model and mimicking C's preprocessor would be a mistake.

9 Likes

I hear you but this leaves us precisely where we were three years ago. Given these constraints only a tactical, incremental change such as that in this proposal (fleshed out and rebased) is a way to take a step forward at this point. This would not preclude moving to the lexer at a later date as it would be functionality the same but there also seems to be a constituency of tooling users who would not be in favour of that anyway so why hold a proposal like this in limbo in perpetuity?

Returned for Revision

This review is circling around two points:

  1. Within the current syntax-based model for condition code, the proposal cannot be reasonably evaluated because the implications are not fully clear in both the written proposal and in the implementation (which is not up-to-date on main). Because the implementation is not up-to-date, the impact of the complexity of the implementation on the compiler is difficult to assess, and the behavior of various corner cases is not clear.

  2. Whether or not the syntax-based approach for conditional code should be abandoned entirely for a different approach, such as a lexer-based one. This creates and existential question of whether this proposed change should even be considered.

The review has waded into debating the second point. To that end, @allevato raised the following reasonable concern:

The core team concurs that such a significant change in direction should have its own properly considered pitch/discussion given the potentially seismic implications. A decision along these lines will not be made as part of this review.

However, the points raised in favor of a lexer-based approach contend that the complexity of the current approach continues to stack up, and is potentially unpredictable to the user. @Chris_Lattner3 framed this perspective succinctly:

In order for this proposal to be considered, the implications of the proposed change needs to be clear. There have been several questions that have been raised in the review that would need to be answered before accepting this proposal as a refinement to the current conditional code model. Thus, the proposal is returned for revision, with the following request:

  1. Update the implementation to work with main so that the implications of the implementation can be understood.

  2. The proposal speaks to the cases brought up here, and sorts through the broader concerns brought up. An updated implementation will be helpful to this end.

With an updated proposal and implementation, the community and core team can properly weigh the cost/benefit tradeoff of this refinement to the current approach, while also providing signal for a potential discussion of moving the conditional compilation to a lexer-based approach. To be clear, it is not a forgone conclusion that a lexer-based approach is an inevitable outcome. As @allevato points out, this deserves sufficient discourse to make such a call.

On behalf of the core team, I'd like to thank both @johnno1962 as the proposal author and everyone who participated in this discussion.

12 Likes

Thank you @tkremenek for bringing this to review even if the outcome wasn't entirely conclusive. In order to avoid situations like this in future could I suggest with appropriate temerity that we introduce a "pre-review" state into the Swift Evolution pipeline. There are 34 open PRs on the swift-evolution repo that could come to review at any time. Would it be possible to schedule proposals of interest to the core team formally by the act of merging the PR (automatically notifying the proposal author and allocating the SE-NNNN number) at least two weeks ahead of time. This would create a sort of "pre-review lobby" which could be on a dashboard somewhere where authors would be motivated to fine tune their proposal, ensure the implementation is up to date and receive final comments from the community before the proposal text is finalised.

All that said, I was able to reproduce a toolchain for the original implementation last night and can give definitive if rather belated answers to some of the questions that came up during the review. I'll not post the toolchain as it is from a time before ABI stability and only builds/works with Xcode 10.1.

This was marked as an error by the implementation. Internally, parsing of collection literals read ahead an expression and a token (skipping any conditionals) to see if the token was ':' or ',' to decide the dictionary/array-ness of the literal and goes down two distinct code paths once that has been determined.

In the original implementation which you can see from my reply to @rintaro's post it was decided to code it to require the trailing ',' inside conditionals. This wasn't strictly necessary and is probably a decision I'd revisit as it creates the need to add commas inside a conditional even if it is defines the last element of the collection.

3 Likes

Hi Ted,

Could the core team provide some guidance of whether the lexer based approach should also be considered? My read of your summary here is that you're asking for a better formed version of the array-only proposal. Is the core team interested in evaluating the larger problem?

-Chris

@Ben_Cohen @Douglas_Gregor Is there any guidance available from the core team here? I'm curious which way you want to see this go.

2 Likes

The review of SE-0335 exhibits another case where lexer-based conditional compilation would help: SE-0335: Introduce existential `any` - #24 by gwendal.roue (with the exhibition of an interesting use case: sharing one doc comment for multiple (conditionalized) declarations of a single documented item).

There is existing guidance from the SE-0308 acceptance:

The core team believes that additional refinement of conditional compilation is something that the language would benefit from. As such, proposals extending support towards conditional compilation of repeated lexical constructs, e.g. elements within an array literal, would be welcome. For non-repeated constructs, there are potential issues with the parsing, for example in the removal of a binary operator may change the operator precedence of subsequent expressions, and this would require careful, deliberate handling. Such a change is not unreasonable, but would demand an appropriate level of design and care towards an implementation.

This guidance stands, and SE-0330 aligns with it. The Core Team is open to considering the lexer-based model, but it would need to presented as its own standalone pitch/proposal. The possibility that such a proposal could be written and accepted should not be used as a reason to reject proposals like SE-0330 that would be subsumed by the lexer model.

(Removes Core Team hat)

I personally would rather see a comprehensive proposal than a lot of piecemeal proposals. For the grammar-based approach, that would be a walk through the whole grammar with updates to allow #if's everywhere they make sense. For the lexer-based approach, it's a model change that removes #if handling from the grammar. I am personally inclined toward the grammar-based approach because I appreciate the ability to build basic syntax trees for the branch not taken, but I'm willing to be convinced.

Doug

7 Likes

To follow-up a bit, the grammar-based approach is about creating syntax-trees in a context-free manner (independent of build settings). The lexer-based approach will practically kill this valuable property of the language.

5 Likes

How is this handled in other languages? :thinking:

Many other mainstream languages these days, outside of C/C++/Objective-C, don't have a preprocessor that allows for the exclusion of arbitrary regions of text. The closest ones to Swift that I'm remotely familiar with that offer a form of conditional compilation are:

C#

C# has #if-style conditional compilation directives that fall somewhere in the middle of C's and Swift's. The untaken branches aren't stripped out completely by a true preprocessor pass; instead, their parsing API appears to take a set of compilation conditions as its input so that it can parse only the branches that are taken into nodes. But the #if directives themselves are preserved in the parsed AST, and the untaken branches are represented as trivia (unparsed raw text).

So, C# allows bizarre constructs like this that Swift would forbid, because it only actually parses the branches taken (notice how Func wouldn't be syntactically correct if NOT_DEFINED was defined):

using System;
					
public class Program
{
	public static void Main()
	{
		double x = 100.0;
		Func(
#if NOT_DEFINED
			x +
#else
			x -
#endif
			10.5);
	}
	
	public static void Func(
#if NOT_DEFINED
		int x
	) {}
#else
		double x
#endif
	) { Console.WriteLine(x); }
}

Rust

I'm far less familiar with Rust, but it looks like it offers a couple different approaches to conditional compilation:

  • A #[cfg()] attribute, which tells the compiler to ignore the language element it's attached to.
  • A cfg! macro that evaluates to true/false at compile-time.

The attribute can handle situations similar to Swift wrapping an entire declaration in #if/#endif, but also applies to lower-level language elements. For example, it supports array literal exclusion:

fn main() {
    println!(
      "{:?}",
      [1, 2,
       #[cfg(target_os = "macos")]
       3,
       4, 5]);
    // prints [1, 2, 4, 5] on a non-Mac system
}

By only being a prefix instead of wrapping the beginning and end of an element, the Rust solution appears to skirt the issue of "should a trailing comma go inside or outside the #if".

It also works nicely for the example @gwendal.roue linked to, although I'm not sure if it's possible to conditionalize the entire function signature—you can conditionalize individual arguments though, which works better in their example anyway:

fn blah(
  #[cfg(target_os = "macos")]
  x: SomeType,
  #[cfg(not(target_os = "macos"))]
  x: SomeDifferentType
) {}

While the previous example highlighted an advantage of Rust's approach being a prefix instead of wrapping, this example highlights a drawback; the condition has to be repeated and inverted instead of just using #else.

But what's also really interesting here is that since this is just a parameter list where each parameter has an attribute attached, rather than excluding a wrapped region of code, the first one must be terminated by a comma, but the second one may not be.

Separately, the cfg! macro can be used in expression contexts, but AFAICT it just evaluates to a true/false boolean, so both branches of an if/else have to be syntactically and semantically valid. For example, you can't mix types:

fn main() {
    println!("{:?}", if cfg!(target_os = "macos") {
        50
    } else {
        "x"
     // ^^^ expected integer, found `&str`
    });
}

Unfortunately, I have no idea what Rust's standard parsing solution is (if it has one), so I don't know if/how these elements are reflected in their syntax tree.

Also, someone please correct me if I've misspoken about any of Rust's capabilities here.


Despite the similarities in C#'s overall parsing and syntax tree API, their approach would lose the benefits that @Douglas_Gregor and @akyrtzi mentioned—being able to parse the entire file irrespective of build conditions is a major benefit, and it makes tools like swift-format possible at all (in their current implementation).

Having researched Rust's approach some more, I'm really fond of it, but I imagine it's a non-starter for Swift since it would be too much of a departure from the #if syntax we already have. But conceptually, it seems like it solves the problems that folks here want solved. I think @Douglas_Gregor's suggestion of just identifying the places in the grammar where #ifs make sense, and then figure out how to adapt it to a model based on open/close delimiters instead of being prefix-only-based.

Then, it's a matter of figuring out how to update the SwiftSyntax APIs to make it easier to peer through the #ifs to get at the actual nodes for each branch. Right now, if a node can be optionally surrounded by an #if, its type degrades to the base Syntax type, and you have to do runtime type-checking/casting to figure out what it actually is. This isn't ideal because losing the strong typing makes it hard to reason about what the tree content is; you can't guarantee that you've covered every possibility exhaustively. If we went this route, then maybe there's a way to represent this with a generic container instead—a IfConfigsAreAllowedHereContainer<ActualNodeType> wrapper that provides accessors for all of its branches, or for the single "null" branch if it's not actually an #if but just regular language elements.

7 Likes

Got it. To summarize my understanding, it sounds like you're comfortable taking micro proposals that expand the support for #ifdef even at the expense of language complexity, but you're also open to a unified theory that subsumes them all.

-Chris

I could quibble that "additional grammar productions" is not necessarily indicative of language complexity in a pragmatic sense, but... yes ;)

Doug

I wasn't referring to implementation complexity. I see it as an accumulation of special cases that make the language more complicated for end users to know "what will work" and "what will not".

The fundamental problem we face (as we project forward further into the future) is that some things will be #if'able and others won't, and the difference will come down to difficult to understand history of how Swift evolved. Why can't I ifdef out a function attribute, or a function parameter, or ....

-Chris

2 Likes

Yes, agreed, which I why I said:

I personally would rather see a comprehensive proposal than a lot of piecemeal proposals.

Doug

It could be possible to use good old C preprocessor before swift compilation phase :rofl:

Terms of Service

Privacy Policy

Cookie Policy