on Sun May 22 2016, Matthew Johnson <[email protected]> wrote:
>> On May 22, 2016, at 1:23 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Fri May 20 2016, Matthew Johnson >> <[email protected] >> <mailto:[email protected]>> >> wrote: >> >>>> On May 20, 2016, at 7:40 PM, Brent Royal-Gordon via >>>> swift-evolution >>>> <[email protected]> wrote: >>>> >>>>> The Any-class requirement could replace the current `AnyObject` >>>>> protocol with a typealias like this: `typealias AnyObject = >>>>> Any<class>` >>> >>>>> >>>>> Assume Swift would introduce Any-struct and Any-enum requirement >>>>> one day. How would one name a typealias for these, where `AnyClass` >>>>> means `AnyObject.Type`? >>>>> >>>>> I suggest we drop the current `AnyClass` and rename `AnyObject` to >>>>> `AnyClass`. If one would need the old `AnyClass` behavior it will >>>>> become `AnyClass.Type`. >>>> >>>> I propose that we deprecate `AnyObject` in favor of `Any<class>`. No >>>> typealias, just directly using `Any<>`. We would also deprecate >>>> `AnyClass` in favor of `Any<class>.Type`. (Presumably we would do >>>> this by providing `AnyObject` and `AnyClass` typealiases in Swift 3, >>>> but marking them as deprecated.) >>>> >>>> I like this approach because it exposes people to `Any<>` and more >>>> quickly gets them to see how it's connected to a protocol >>>> declaration's conformance list. They might then guess that `Any<>` >>>> has other capabilities from that list, like the ability to handle >>>> multiple protocols. >>>> >>>>> In the future we could have typealiases like this, which are more clear: >>>>> >>>>> `typealias AnyClass = Any<class>` >>>>> `typealias AnyStruct = Any<struct>` >>>>> `typealias AnyEnum = Any<enum>` >>>> >>>> Even in the long term, I don't see any good reason to support >>>> `Any<struct>` vs. `Any<enum>`. There is no semantic distinction* >>>> between a struct and an enum; you can always implement something >>>> enum-y using a struct with a mode field, or something struct-y using >>>> an enum with associated values. `Bool`, for instance, was once an >>>> enum and was changed to a struct for implementation reasons; this >>>> change made no difference to how it was used. >>>> >>>> Now, there *is* a semantic distinction between struct/enum and >>>> class—one is a value type, the other is a reference type. To support >>>> that distinction, it might make sense to support an `Any<value>` or >>>> `Any<!class>` syntax. Again, I would prefer to use the raw `Any<>` >>>> syntax, though, not a typealias. >>> >>> You can implement reference types with value semantics and value types >>> with reference semantics. Until the compiler can verify value >>> semantics I am not sure there is a benefit to `any<value>`. The >>> semantic distinction is what is important. There has been discussion >>> about strengthening the “value type == value semantics” and “reference >>> type == reference semantics” relations but that hasn’t yet moved >>> beyond talk. >>> >>>> >>>> (I've read the arguments about pure vs. non-pure value type >>>> conformances and I'm not convinced. It is always possible to >>>> nominally "conform" to a protocol in a way that actually undermines >>>> its guarantees; for example, you could implement >>>> `RangeReplaceableCollection.remove(at:)` as a no-op. The compiler >>>> cannot reject all invalid conformances; it can only reject ones >>>> which it can trivially show are invalid, because for instance they >>>> do not even attempt to provide a required method. Similarly, the >>>> compiler may not be able to prove you are providing value semantics, >>>> but it *can* reject conformances of reference types to a protocol >>>> requiring value semantics, since those cannot possibly be valid >>>> conformances. >>> >>> Immutable reference types actually *can* provide valid value semantics >>> (at least as long as as they can provide their own implementation of >>> `==` which I believe Dave A is arguing against). >> >> I am not making a strong argument against that, though it might be >> reasonable. I am mostly arguing in favor of a default definition of == >> for all reference types that is equivalent to ===. > > Sorry I misunderstood. To make sure I understand clearly: you’re not > arguing against reference types with value semantics, just that we > should allow reference semantics to be assumed unless custom equality > is implemented. Is that correct? I don't view an immutable class with custom equality as problematic in principle, but if dropping that capability would allow us to simplify the programming model, I would do so in a heartbeat. I haven't had the chance to consider all the implications yet, but—at least until someone can demonstrate that we really custom == for classes—we should be open to the idea as we consider the value semantics story. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
