Oh yes you’re right.
I didn’t consider that case; thanks.
On 13 Mar 2017, at 15:34, rintaro ishizaki
<[email protected]<mailto:[email protected]>> wrote:
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
<[email protected]<mailto:[email protected]>>:
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
[email protected]<mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
