Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion from the first RFC that's worth noting here:
I personally agree that we should come up with a much better name than Π types for this. We're not gonna use that name in the Rust book, and while understanding type theory is necessary for implementation, I don't think it's necessary for the average user.
I'll make time to read these in the next few weeks, but so far my reading beyond the first amounted to ctrl-F "lifetime", but..
I wondered if one could create a value type from a runtime value and lifetime, so that the value acted as basically an implicit parameter, while the lifetime dictates where the proof must resolve. As an example :
Imagine we've some crate that requires a struct
I think 3 will become increasingly popular regardless, but const dependent types, or just a fragment there of, makes doing so clean and idiomatic, as opposed to a morass of trait hacks, and they let you avoid unsized types.
Now can we push this messy trait based
You can nevertheless imagine an implicit parameter being set by a type, and the compiler being asked to prove its correctness, even if under the hood this parameter gets passed at runtime.
Can you return a
I think 2 actually provides a useful way to imagine these hypothetical "lifetime dependent types". There is some lifetime
Apologies for rambling here.
Hmm, I'm not sure I buy that.
Right. From the last time I was confused about this and researched it, I believe there are at least three superficially similar but different beasts in this space: existentials, weak sums, and strong sums. I think "sigma type" applies to both of the latter(?), but that it's usually used to mean strong sums. The difference is best discernible if you have a local variable or a top-level constant of the type, that is, whose definition is also in scope. If we think of each of the three as a pair where the type of the second component may refer to the 'value' of the first, then with existentials, the first component is always erased (even if it's "visible in the source"), and can only be used as an abstract (unknown) value; with weak sums, the first component gives back the same value you put in, but when accessing the second component, its type again refers to an abstract placeholder value in place of the first component; while with strong sums, when you access the second component, its type retains full knowledge of the first's value as well ("dependent elimination"). It's the last of these which is usually referred to as a "dependent pair".
So I believe Rust's trait objects correspond to existentials, and its slices to weak sums.
(Unfortunately I didn't save the links where I read about this, but if anyone's interested, hopefully googling should lead to the same results.)
This paper might be relevant:
It proposes adding a subset of dependant types to a mutable Java-like language by tracking aliases and using move semantics.
It can be fully verified at compile time.
Any linear inequality over the integers is a valid constraint.
As such I think it could fit in with the Rust paradigm very well.