Not sure what to think about the enum cases inside a
protocol (if AnyEnum would
even exist), it could be a nice addition to the language, but
this is an own
proposal I guess.We should start by adding AnyValue protocol to which all value
types
conforms.Having a way to constrain conformance to things with value semantics
is
something I've long wanted. *However*, the approach described is too
simplistic. It's possible to build classes whose instances have
value
semantics (just make them immutable) and it's possible to build
structs
whose instances have reference semantics (just put the struct's
storage
in a mutable class instance that it holds as a property, and don't
do
copy-on-write).In order for something like AnyValue to have meaning, we need to
impose
greater order. After thinking through many approaches over the
years, I
have arrived at the (admittedly rather drastic) opinion that the
language should effectively outlaw the creation of structs and enums
that don't have value semantics. (I have no problem with the idea
that
immutable classes that want to act as values should be wrapped in a
struct). The language could then do lots of things much more
intelligently, such as correctly generating implementations of
equality.That is a drastic solution indeed! How would this impact things like
Array<UIView>? While Array itself has value semantics, the aggregate
obviously does not as it contains references which usually be mutated
underneath us.Value semantics and mutation can only be measured with respect to
equality. The definition of == for all class types would be equivalent
to ===. Problem solved.Similar considerations apply to simpler wrapper structs such as Weak.
Same answer.
Hmm. If those qualify as “value semantic” then what kind of structs and
enums
would not? A struct wrapping a mutable reference type certainly doesn’t
“feel”
value semantic to me and certainly doesn’t have the guarantees usually
associated with value semantics (won’t mutate behind your back, thread
safe,
etc).Sure it does.
public struct Wrap<T: AnyObject> : Equatable {
init(_ x: T) { self.x = x }
private x: T
}func == <T>(lhs: Wrap<T>, rhs: Wrap<T>) -> Bool {
return lhs.x === rhs.x
}I defy you to find any scenario where Wrap<T> doesn't have value
semantics, whether T is mutable or not.Alternately, you can look at the Array implementation. Array is a
struct wrapping a mutable class. It has value semantics by virtue of
CoW.This goes back to where you draw the line as to the “boundary of the value”.
Wrap and Array are “value semantic” in a shallow sense and are capable of deep
value semantics when T is deeply value semantic.No, I'm sorry; this “deep-vs-shallow” thing is a fallacy that comes from
not understanding the boundaries of your value. Or, put more
solicitously: sure, you can look at the world that way, but it just
makes everything prohibitively complicated, so why would you want to?In my world, there's no such thing as a “deep copy” or a “shallow copy;”
there's just “copy,” which logically creates an independent version of
everything up to the boundaries of the value. Likewise, there's no
“deep value semantics” or “shallow value semantics.”
Equality defines
value semantics, and the boundaries of an Array value always includes
the values of its elements. The *only* problem here is that we have no
way to do equality comparison on some arrays because some types aren't
Equatable. IMO the costs of not having everything be equatable, in
complexity-of-programming-model terms, are too high.
Thank you for clarifying the terminology for me. This is helpful.
I think I may have misunderstood what you meant by “boundary of the value”. Do you mean that the boundary of an Array value stops at the reference identity for elements with reference semantics? If you have an Array whose elements are of an immutable reference type that has value semantics would you say the boundary extends past the reference identity of an element and includes a definition of equality defined by that type?
Are you arguing that reference types should be equatable by default, using equality of the reference if the type does not provide a custom definition of equality?
Both have their place, but the maximum benefit of value semantics
(purity)I don't know what definition of purity you're using. The only one I
know of applies to functions and implies no side effects. In that
world, there is no mutation and value semantics is equivalent to
reference semantics.
I was using it in the sense of “PureValue” as discussed in this thread. I was using it to mean values for which no *observable* mutation is possible (allowing for CoW, etc). Is there a better term for this than purity?
is derived from deep value semantics. This is when there is no
possibility of shared mutable state. This is an extremely important
property.It's the wrong property, IMO.
Wrong in what sense? I don’t mean to imply that it is the *only* valuable property. However, it I (and many others) do believe it is an extremely valuable property in many cases. Do you disagree?
let t = MyClass()
foo.acceptWrapped(Wrap(t))
t.mutate()In this example, foo had better not depend on the wrapped instance not getting
mutated.foo has no way to get at the wrapped instance, so it can't depend on
anything about it.
Ok, but this is a toy example. What is the purpose of Wrap? Maybe foo passes the wrapped instance back to code that *does* have visibility to the instance. My point was that shared mutable state is still possible here.
···
On May 5, 2016, at 10:02 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Thu May 05 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:On May 5, 2016, at 4:59 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Wed May 04 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
on Wed May 04 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
on Wed May 04 2016, Adrian Zubarev <swift-evolution@swift.org> >> wrote:
My expectation is a generic aggregate such as Array would have to
conditionally conform to AnyValue only when Element also conforms to
AnyValue.I’m also wondering how such a rule would be implemented while still
allowing for CoW structs that *do* implement value semantics, but do
so while using references internally.I am not talking about any kind of statically-enforceable rule, although
we could probably make warnings sophisticated enough to help with this.You said the you have arrived at the opinion that the language should
“effectively outlaw” structs and enums that do not have value semantics.
That
sounded like static enforcement to me.The language outlaws certain kinds of inout aliasing without
providing static enforcement. This is like that.I did not know this. Now you have me curious. Can you give an example of where
we are able to violate law? I ask mostly because it sounds like there is a
possibility of stumbling into dangerous territory, possibly without being aware
that you have done so.See “In-out Parameters” in
The Swift Programming Language: RedirectMaybe you meant we should allow the compiler to assume value semantics
for structs and enums despite the fact that it doesn’t statically
enforce this?That would be one *consequence* of effectively outlawing it. The library
could make similar assumptions.If the compiler can be sophisticated enough to verify value semantics
statically maybe it would be better to have that mechanism be
triggered by conformance to AnyValue rather than for all structs and
enums. Types that conform to AnyValue would receive the benefits of
the compiler knowing they have value semantics, while other uses of
structs and enums would remain valid. Best practice would be to
conform structs and enums to AnyValue whenever possible.Another possible advantage of this approach would be allowing
immutable reference types to conform to AnyValue and receive the
associated benefits such as the generated implementation of equality,
etc.-Matthew
--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
Dave--
Dave