Joe-
I hadn't seen that proposal; it would make sense to harmonize with enum cases.
Instead of the trailing "behavior unowned" syntax, perhaps your proposed
bracket syntax could be used:
enum ChildGuardianship {
case [unowned] ChildOf(Parent)
case [indirect] GrandChildOf(ChildGuardianship)
Another way to address this might be by allowing property behaviors, a feature
proposed in
https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md
to allow for factoring out property implementations, could also apply to
`case` declarations. "Weak" and "uno
> This means that the ChildGuardianship enum is no longer a real value type
> with value semantics but a value type with partial reference semantics.
That's already true of any enum that has an associated reference type.
> On May 6, 2016, at 10:26 AM, Michael Peternell
> wrote:
>
>
>> Am 0
> Am 06.05.2016 um 14:08 schrieb Marc Prud'hommeaux :
>
>
>> I wonder if there is a practical use-case for this.. Is there? Just
>> curious...
>
> Without getting too deep into the weeds of our specific data modal, I'll
> summarize with "yes". If you need to mix classes with enums and don't h
> I wonder if there is a practical use-case for this.. Is there? Just curious...
Without getting too deep into the weeds of our specific data modal, I'll
summarize with "yes". If you need to mix classes with enums and don't have the
ability to declare the storage class of the variables, then re
I wonder if there is a practical use-case for this.. Is there? Just curious...
-Michael
> Am 03.05.2016 um 17:07 schrieb Marc Prud'hommeaux via swift-evolution
> :
>
>
> The following code currently has a retain cycle and memory leak:
>
> enum ParentChild {
> case SonOf(Parent)
> case
Why not separate the reference and its info? That way you can make the
reference weak.
enum ParentChildRelationship {
case Son
case Daughter
}
class Parent {
lazy var son: Child = Child(sonOf: self)
lazy var daughter: Child = Child(daughterOf: self)
deinit { print("deinit
It’s an interesting idea, but with the workaround you’ve found I wonder if it
might make more sense to just have Unowned and Weak in the standard
library? I’ve already defined these myself to work with a few awkward cases and
to allow entries in collections to be weakly referenced.
I mean it’d
I would like to see something like this; it would not only eliminate extra
code, but could potentially be more efficient.
What syntax do you propose? If enum values were always labelled, I would expect
something like SonOf(weak parent: Parent), but there would probably be
resistance to allowing
The following code currently has a retain cycle and memory leak:
enum ParentChild {
case SonOf(Parent)
case DaughterOf(Parent)
}
class Parent {
lazy var son: Child = Child(parentChild: .SonOf(self))
lazy var daughter: Child = Child(parentChild: .DaughterOf(self))
deinit { pri
10 matches
Mail list logo
