Begin editing pass #2
Conversation
| ...`; you may have to transfer ownership around based on the site of the last use. I think of our | ||
| bindings as being like reader/writer locks: there are either multiple owners through which the | ||
| object is immutable, or one owner through which it is mutable. | ||
|
|
There was a problem hiding this comment.
Okay, I like this analogy! single-writer/multiple-reader is a very well-established principle, so it might be easier to build on that.
|
|
||
| The whole idea of “changing the capabilities of a program's bindings depending on its control flow” | ||
| seems pretty magical and mysterious to me. | ||
|
|
There was a problem hiding this comment.
There's a dynamic aspect that we need to address. There might be a simpler model than capabilities, but I think we can't avoid talking about "control flow". The challenge is to distill the fact that Val's type system has a flow-sensitive component that can only be understood by thinking about execution.
|
|
||
| Seems to me the above list can't be complete. There can also be no access to an object to a | ||
| mutably-owned object except through its owner. | ||
|
|
There was a problem hiding this comment.
I think that property derives from 2 and 3. But if we use the single-writer/multiple-reader model we probably can come up with different "basic principles".
There was a problem hiding this comment.
I don't think it derives, for two reasons. First, 3 is decoupled from ownership; it isn't mentioned. Do you want to say you can only access an object through its owner?
Second, there's no rule that prevents an immutable access from occurring during a mutable access.
There was a problem hiding this comment.
You are right. My rules are insufficient. I will change this part following our discussion about the "simple" model.
| @@ -241,6 +288,9 @@ public fun main() { | |||
| print(weight) // 2.3 | |||
| } | |||
| ``` | |||
| {% comment %} | |||
| The ability to use (e.g.) an integer literal to initialize a double is IIUC one of the great sources of expression too complex errors in Swift. | |||
| {% endcomment %} | |||
There was a problem hiding this comment.
I believe Val does not suffer from combinatorial explosion during type inference for the following reasons:
- I don't think we should have (public)
ExpressibleBy***Literaltraits, so the search space is bounded and we can teach the compiler how to propagate top-down type assumptions through operators. - Operators are methods of the LHS.
- We don't have type-based overloading.
When the compiler sees let n = 1 + 2.3 + 4, it will complain about a type error in linear time. Without annotations, 1 is inferred as Int and Int.infix+ forces 2.3 to have type Int.
There was a problem hiding this comment.
Neither of us should make strong predictions in this space without a clearer understanding of what slows Swift down.
There was a problem hiding this comment.
My beliefs about Swift's implementation come from this blog post (which might not be completely up to date). I remember working on that problem for the language I developed in my thesis and managing to infer relatively "complex" arithmetic expressions just by bounding the set of types that may conform to ExpressibleBy***Literal.
But I never formally investigated the complexity of my inference algorithm, neither of Swift's. So it's fair to avoid making strong statements at this point.
Not sure how this process will play out, but we'll figure it out.