Am 11.11.2012 18:20, schrieb Robert Jacques: > > What's wrong with std.typecons.Unique?
- Does not implicitly cast to immutable - Has no way to enforce uniqueness of data referenced within the contained object - Cannot be passed between threads (i.e. in std.concurrency) and if it would be passable, it would not be safe - Does not allow temporal elevation to non-unique in pure contexts - No support for arrays and unique partitions Probably more, but basically in its current form it's mostly useless apart from documenting the intent. Some of the things can be fixed in the library type, but to make it really sound and useful, a library solution is not enough (at least not with the current means that the language offers). > By the way, back when concurrency in D was actively being discussed and > developed, (IIRC) Walter did try to implement unique as a proper type in > D, but ran into several gotchas. Do you remember which? All I could find was a thread stating that Walter did not like the idea of adding an additional transitive type modifier along const, immutable and shared because of the combinatorial number of types. Oddly, I could have sworn that I have commented on unique at that time, but can't find that either. > In essence, while we all want > unique/mobile, for unique/mobile to be non-broken it also needs at least > a lent/scope and an owned type. The system described in the paper does not need need lent/owned types. That can be attributed to the fact that their function definition disallows access of mutable global fields. So as long as only 'pure' functions operate on a given 'isolated' value, their recovery rules allow working pretty comfortable, while still statically enforcing memory isolation. Calling normal, impure methods or functions would have to break the 'isolated' property and inhibit recovery. This would be the place where the system with 'lent'/'owned' would allow more freedom, but only at the cost of a generally higher complexity. > Ownership type systems are a relatively > new area of CS and as demonstrated by the paper, still an active area of > research. The thorny issue of these systems is that you need to > associate variables with types. For example, this.x = that.y; is only > valid if x and y are both owned by the same region. This is easy to > verify at runtime, but not at compile-time. At least the following assignments can be verified statically using only local information, no need to track exact memory region ownership: unique <- unique immutable <- unique writable <- unique writable <- writable this.x = this.y inside an 'isolated' memory region would be valid as long as it happens in a pure context and no non-unique/non-immutable values are passed into the function. Anything else would inhibit recovery of 'isolated' after the implicit conversion to 'writable' that is necessary to pass the object to a function/method. > Anyways, ownership types (or > whatever supersedes them) were pushed back to D3 and we were left with > message passing for the common user, synchronized for traditional > lock-based shared memory and shared for lock-free programming. Yeah, I'm well aware of that.. unfortunately ;) This system has the potential to be backward (vs current state) and forward (vs a full ownership system) compatible, while not affecting anything of the existing language (like needing to store explicit ownership information). However, I have to admit that without actually trying it and seeing how usable it is first hand, it's difficult to tell how usable it is in practice (e.g. because D functions have to be explicitly tagged 'pure' for the recovery to work). Maybe also error messages would be difficult to understand or something else.
