Open jemc opened 2 years ago
Note that one downside of this is that if the type inferred for the expression becomes more general (like if it goes from Foo.Bar
to (Foo.Bar | None)
), then this kind of shorthand syntax becomes untenable. This means that what appears to be a non-breaking change (an API that accepts a broader range of values at its input) can actually break compilation for call sites using the shorthand syntax (it will no longer have a single type to refer to as its antecedent).
However, this is not a unique disadvantage that would be introduced by this feature - it is already present in other type inference related features, like array inference that can infer the type of array to instantiate based on the antecedent type, but fails to do so when there is more than one array-like option in the antecedent types.
Marking this as blocked by the type system rewrite in #76.
Swift has this nifty feature they call Implicit Member Expression, which is often used for enums, but can also be used for static functions/variables.
In Savi we could use a similar feature for enums, static functions (
fun non
) and constructors (new
).The basic idea is that if the expression
.baz
can be used as shorthand forFoo.Bar.baz
in a place where the type inference system knows that the typeFoo.Bar
is expected.Here are some examples of places in real Savi code that could be made more succinct: