Conversion of complex binary expressions results in "Expression was too complex to be solved ..." error

Description

NewVideoRecorder / KZCameraView.swift:

converts to:

.. which gives the following error:
http://take.ms/7fGMK

A possible solution is refactoring this to extract separate variables, i.e.:

Environment

Xcode 9.3

Activity

Show:
Alex Petuschak
April 6, 2018, 2:24 PM
Edited

Same issue (FlipsideViewController.swift / FrameCruncher project):

converts to

... and gives the same error:
http://take.ms/z8C9A

This is also solvable by extracting intermediary `dx` and `dy` variables:

Alex Petuschak
April 6, 2018, 3:10 PM

Just tried to enable generation of `if let` statements for binary expressions and got the following result, which compiles without issues:

Currently, we do not generate `if let` statements for this case for 2 reasons:
1) Unwrapped arguments (i.e. `touch1?.x`) have an primitive type (CGFloat), thus we resort to using `??` operator;
2) Unwrapping using `if let` statements was not enabled for binary expressions.

I am fine to enable `if let` statements for binary expressions (2).
However, I am still in doubt about using `if let` statements to unwrap expressions of primitive types such as Int, Float or String (compared to using `??` operator as implemented now).

To compare, here is how the first function from the default code sample on our website looks after I disable checks (1) and (2) above:


What do you think about cases like above (unwrapping primitive type binary expression operands) - should we switch from `??` operator to `if let` for these cases?

The compiler issue seems very well known:
https://stackoverflow.com/questions/29707622/swift-compiler-error-expression-too-complex-on-a-string-concatenation

Of course, we can make this a configurable option later, but as I mentioned, this multiplies the amount of testing so I am yet targetting to produce the single, best possible output.

Keegan Rush
April 9, 2018, 12:52 PM

Hey ,

The problem here is due to an immature compiler (struggling with complex expressions), as opposed to syntax errors (which are the usual bug fixes that we need to do).

Following this approach to fix this creates 2 issues, in my opinion:
1. The `if let` simply doesn't read as nicely as the nil-coalescing operator in many examples
2. Wrapping it in an `if let` could actually create more compilation errors than it solves

Regarding #2, in the example you gave from the default code sample, `plane` is now an Optional<SCNPlane> where it was previously a non-optional SCNPlane. Should we be worried about this causing compilation issues in larger functions?

From the little bit of context I've seen in this ticket, I'd suggest leaving things as they are. I wouldn't want to negatively change how we convert these expressions 100% of the time, just for the small chance that the expression may be too complex for the Swift compiler.

Alex Petuschak
April 10, 2018, 11:28 AM

Hey ,

I agree with your suggestion to treat this as a lower priority and leave the things "as is" for now.

Still wanted to pass this through you since
(1) This compiler bug has started to happen only after I've implemented unwrapping with `??` operator (), and
(2) I've noticed this same issue with 2 different projects, during 2 consecutive days
(while I was analyzing the impact of the recent changes in the error rate with actual projects).

in the example you gave from the default code sample, `plane` is now an Optional<SCNPlane> where it was previously a non-optional SCNPlane. Should we be worried about this causing compilation issues in larger functions?

If we use an `if let` statement, we also treat the `plane` variable as optional in our converter.
As you see, the further code is correctly unwrapping the variable:

So, in short, we already do a decent job when unwrapping optionals, although there are few more related scheduled improvements.

If still we ever want to address this JIRA issue, my current "best guess" is unwrapping only non-trivial expressions (i.e., everything but a single identifier or property/message expression) using `if let` statements.

Alex Petuschak
February 12, 2019, 11:50 AM

Related: after upgrading to Xcode 10.2 beta 2, I got 3 "The compiler is unable to type-check this expression in reasonable time" errors in the Tip Tap Too project:
https://take.ms/CBobv

The failing code looks like follows:

Assignee

Alex Petuschak

Reporter

Alex Petuschak

Labels

None

Git Branch Name

None

GitHub Issue

None

Components

Fix versions

Priority

Low
Configure