-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: support linear types #55657
Comments
TL:DR: Interesting thought experiment. I don't see this happening as a Dart language feature. It will be far too intrusive for the type system. If linear types are types whose variables are linear variables, meaning that they can/must be read only once, then it's probably something Dart can do. To some extent. The underlying wish is to avoid aliasing, that a given "linear object" only ever has one reference. (Or at most one reference, if we ever want to GC it.) Let's start with linear variables. A linear variable is a variable whose value must be used (read) precisely once. (We can make it affine instead, and say it must be read at most once, then you can leave the value to rot if you want to.)
That suggests a modifier that replaces There are some design issues around the "must be read once" rule. It means you cannot return when a linear variable is potentially assigned. But for full consistency, you also cannot throw then, and we definitely cannot prevent that. That's probably why you'd want linear types, to make restrictions on all occurrences, not just variables. Let's say we declare That doesn't fit that well into the Dart type system.
So, most likely, we'll have to have
The type
I think the proper supertype is the most consistent model, and it means that all existing generics, which have at most Then we'll have to write new linear collections. If that even makes sense. A linear array is a sequence of linear variables, which are cleared when they are read. The API must make it possible to detect whether a position holds a value. That may be impossible if we take the linear property literally. More likely we'll need to consider calling methods on a linear type to not count as a use. Or some other allowance for locally keeping multiple references to the same object, as long as at most one of them survives at a point where the reference is passed to someone else. You can read a linear variable containing a value more than once, as long as all you use it for is calling methods on it. Those methods must then not use Now we're getting there:
The "not passing to functions" annoys me. If a linear variable is passed as argument, we don't know whether the function will hold on to it or not. If it can (which likely means allowing the variable to be captured in a closure), then it's possible to hold on to the value indefinitely. It would be nice to have a way to say that a variable is only valid for the duration of the call, and cannot be captured. All in all, there might be a possible design that can provide some notion of linearity of values.
|
Thanks for considering this so thoughtfully. I am convinced the full language feature is of unrealistic scope, but also convinced there's got to be some way for dart-analyzer to help careful programmers & FFI users if not performance. One note is whether you want to go all the way and allow flexible coupling of linearity to existing types, e.g. I was imagining something closer to the latter because of its suitability for incremental, annotation-driven usage. Also worth mentioning on |
Moved back to SDK repo and made an anlyzer issue. (They can then consider whether it should be a lint or not.) |
Consider supporting linear types. Wild proposal for a reasonably major direction. Didn't see it discussed here or in the Google Group. Even something simple like an '@NoCopy' annotation would be useful.
A few basic points:
meta
already has@useResult
and@immutable
.Lots of languages have bolted on linear typing or linear-like features. In Dart's case, it might make sense to do at the analyzer level at first and expose piecemeal features driven by the same underlying analysis such as something like
@noCopy
annotation, etc. Then a real design for the type system for Dart 5 or whatever could subsume those features.The text was updated successfully, but these errors were encountered: