[swift-evolution] Inconsistencies in recursive types

[rintaro ishizaki]

FWIW, there *is* a way to instantiate #4 case.

class First {
    let item: First
    init(item: First) {
        self.item = item
    }
}

class Second : First {
    init() {
        super.init(item: self)
    }
}


let a: First = Second()

2017-03-13 22:38 GMT+09:00 Dimitri Racordon via swift-evolution <
swift-evolution at swift.org>:

> Hello swift-evolution,
>
> I noticed there’s some inconsistencies with recursive types and how the
> compiler handles them. Consider the following cases:
>
>
> *1. Swift is right to refuse compiling this, since there’s no way to
> initialise an instance of `First `:*
>
> struct First {
>     let item: First
> }
> // Error: Value type 'First' cannot have a stored property that references
> itself
>
> However, the message suggests more a compiler limitation rather than the
> actual impossibility to initialize the declared type.
>
>
> *2. Swift is also right not to compile this, but the error messages are
> even less insightful:*
>
> struct First {
>     let item: Second
> }
> // Error: Value type 'First' cannot have a stored property that references
> itself
>
>
> struct Second {
>     let item: First
> }
> // Error: Value type 'Second' cannot have a stored property that
> references itself
>
> The problem isn’t that the value types reference *themselves*. Instead,
> the problem is that there’s a cyclic dependency between `First` and
> `Second` that makes it impossible for neither of these structures to be
> instantiated.
>
>
> *3. Swift should let me do that:*
>
> struct First {
>     let item: First?
> }
>
> The compiler prevents me to declare the above struct, even if there
> actually is a way to initialise an instance of `First` (e.g. `First(item:
> nil)`). The message is identical to that of case #1 (maybe it actually
> *is* a compiler limitation after all?)
>
>
> *4. Swift shouldn’t compile this:*
>
> class First {
>     let item: First
>     init(item: First) {
>         self.item = item
>     }
> }
>
> Like in case #1, there’s no way to instantiate `First`. The fact that it’s
> a reference rather than a value doesn’t change the problem.
>
>
> *5. Similarly to case #4, Swift shouldn’t compile this:*
>
> indirect enum First {
>     case item(First)
> }
>
>
> *6. Cases #4 #5 could be written like case #2, and should also raise
> compilation errors.*
>
>
> Does someone know if these issues have already been discussed and/or
> addressed?
>
> Thanks,
> Dimitri Racordon
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170313/e25c8507/attachment.html>