I like the idea of Clonable, because it involves the least amount of
boilerplate and I do certainly agree that not having to care about whether or
not the object is a value type or a reference type is good for robust generic
programming.
However, there are two problems that I see with it:
* The
on Tue Jul 25 2017, Gor Gyolchanyan wrote:
> I like the idea of Clonable, because it involves the least amount of
> boilerplate and I do certainly agree that not having to care about
> whether or not the object is a value type or a reference type is good
> for robust generic programming.
>
> Ho
on Wed Jul 12 2017, Gor Gyolchanyan wrote:
> Hello, swift community!
>
> Recently I’ve come across a dilemma regarding value-type semantics
> when dealing with generic types. Consider a protocol that has a
> mutating in-place function and a non-mutating returning variant of
> that function:
>
>
Yes, NSNumber was a bad example. Immutable types can implement it and do a
shallow copy, as you said.
The NSCopying protocol won’t do because:
It only works on @objc classes.
Its proper use is deprecated (namely, the use of provided NSZone parameter is
deprecated).
It’s in Foundation framework, w
> On Jul 12, 2017, at 3:23 AM, Gor Gyolchanyan via swift-evolution
> wrote:
>
> Hello, swift community!
>
> Recently I’ve come across a dilemma regarding value-type semantics when
> dealing with generic types.
> Consider a protocol that has a mutating in-place function and a non-mutating
>
Hello, swift community!
Recently I’ve come across a dilemma regarding value-type semantics when dealing
with generic types.
Consider a protocol that has a mutating in-place function and a non-mutating
returning variant of that function:
protocol Transmogrifier {
mutating func transmogrify(
