Skip to content

Instantly share code, notes, and snippets.

@dduan
Last active April 10, 2017 20:31
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dduan/5017a0b0f0880d014f4ce14c4ca7fb55 to your computer and use it in GitHub Desktop.
Save dduan/5017a0b0f0880d014f4ce14c4ca7fb55 to your computer and use it in GitHub Desktop.

Remove type inference for stored properties

Introduction

When a type's stored property is declared with a default value, user may choose to let Swift's compiler to automatically deduct type for this property instead of writing it explicitly. We propose this feature be removed from Swift.

Swift-evolution thread: Remove type-inference for stored property

Motivation

On the surface, inferencing types from default value makes the experience of declaring stored values inside types easy and student-friendly. But this benefit diminishes quickly as users progress to more serious settings using Swift.

  1. The student-friendliness breaks down as soon as protocols or computed properties are introduced. While similar, type inference aren't available in those scenarios.
  2. Type inference is not available for function/method parameters with default values.

It's hard to explain these inconsistencies to expert users (they really shouldn't care about that reason, really), let alone a person learning Swift. Everyone eventually has to accept the differences as a matter of fact.


Even though the compiler is capable of saving programmer from writing the type, readers of the result end up having to infer the type themselves.

  1. Readability and complexity of the default value expression has a inverse relationship. The more complex the expression is, the harder it is to infer the type. This is true for both humans and the compiler (more on this on the next section).
  2. This is a general problem for type inference. Declarations for stored properties, however, serve more as documentation than local variables, as they are part of the API.

Clarity for code readers should have more weight than ease for authors.


As of this writing, type inference on stored property has caused performance problems in the compiler. Slava Pestov detailed them here. While the issues are partially due to current implementation, it's unclear how much space for improvement there is. Compiling speed affects developer productivity a great deal. We should consider lowering the theoretical upper bound of compiler performance a valid motivation for a language change.

Proposed solution

Deprecate type inference on stored property inside type declarations. Users will have to write out types explicitly for each property.

Detailed design and source compatibility

When a stored property declaration has only a default value and no explicit type, the compiler will issue a warning saying that type inference there will be removed in the next major Swift release. Along with the warning is a fix-it that fills in the type that the compiler inferred. With the next major version of Swift, this warning will become an compile error.

Note that the compiler may choose to keep the inference functionality in various forms. For example, the fix-it may continue to exist as part of error-recovery (aka only attempt to infer one the error is encountered).

Effect on API stability and resilience

None

Alternative Considered

Type inference is a beginner friendly feature. It is tempting to keep it in "beginner environments". That is, we allow this feature in Playgrounds with a special compiler flag. We rejected this idea because it creates dialects of Swift, towards which core team member Chris Lattner has expressed animosity.

We may also choose to keep type inference in stored property and await for more efficient compiler implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment