> On Mar 14, 2017, at 2:13 AM, Dimitri Racordon <[email protected]>
> wrote:
>
> Thanks a lot for your very detailed explanations!
>
> So my only issue regarding #1 #2 and #3 is the error message, which really
> doesn't suggest the actual underlying problem.
>
> Regarding #5 and #6, I still feel like the compiler should complain about it.
> I disagree on the fact that it shouldn't be it's role to disallow
> uninitializable code, unless using unsafe techniques. This imho isn't
> consistent with some other errors the compiler does emit for ill-defined
> types.
That’s the thing though, they aren’t ill-defined. Just because a type cannot be
initialized does not mean it is not useful.
1. Namespacing
I admit this is a kind of hacky use, but there’s not better way right now.
enum Geometry {
struct Point {
var x: Int
var y: Int
}
}
let p = Geometry.Point(x: 0, y: 0)
2. Uninhabited Types
Swift uses `Never` as the return types of functions that can never return (e.g.
`fatalError`). Since `never` is an enum with no cases, it is not possible to
construct one. This indicates to the type system that the function will not
return.
func runloop() -> Never {
while true {
print("Hello again!")
}
}
let result: Never = runloop()
// Since a `Never` type cannot be constructed,
// we will not pass this line.
3. Phantom Types
Sometimes an uninhabited type is useful for providing information in the type
system without creating an instance of the type itself. These tags can be used
to provide additional behavior to the type or to provide additional type
safety. Here’s another example
<https://gist.github.com/JadenGeller/f39130616846f9bf9879> and some reading
<https://wiki.haskell.org/Phantom_type>.
enum Unvalidated { }
enum Validated { }
struct User<V> {
private(set) var name: String
private(set) var age: Int
}
extension User where V == Unvalidated {
init(name: String, age: Int) {
self.name = name
self.age = age
}
func validated() -> User<Validated>? {
guard age > 18 else { return nil }
return User<Validated>(name: name, age: age)
}
}
func register(_ user: User<Validated>) {
print("\(user.name) is registered!")
}
if let me = User<Unvalidated>(name: "Jaden Geller", age: 21).validated() {
register(me)
}
Cheers,
Jaden Geller
> On 13 Mar 2017, at 22:20, Jaden Geller <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Comments inline:
>>
>>> On Mar 13, 2017, at 6:38 AM, Dimitri Racordon via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> 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.
>>>
>>
>> This is a compiler limitation that isn’t going to go away. Structs are value
>> types whose size is equal to the sum of their property sizes. Here, we have
>> a circular dependency, so it is impossible to compute the size.
>>
>> This is not an arbitrary restriction. Consider:
>>
>> struct List<T> {
>> var head: T
>> var tail: List<T>?
>> }
>>
>> The size of `List` is infinite! Every `Optional<T>` must be big enough to
>> store the type `T` in case the value is not `nil`. Thus, `List` must be big
>> enough to store a `T` AND another list (of the same size):
>>
>> size(of: List<T>) = size(of: T) + size(of: List<T>)
>>
>> It’s easy to see that, assuming `size(of: T)` is non-zero, it is impossible
>> to satisfy this constraint. Yes, Swift could special case the case where
>> there are no other members, but this would be entirely useless (you can’t
>> store state) and would considerably muck up the semantics.
>>
>> Note that enums allow members to be marked `indirect`. This would be a
>> reasonable feature for Swift to eventually support for structs as well. In
>> this case, the indirect member would be the size of a pointer, so the size
>> would be statically known and satisfied.
>>
>>>
>>> 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.
>>>
>>
>> This is an identical problem to #1. The error message could probably be
>> improved. This isn’t a “reference” in the sense of a pointer, but in the
>> sense that there is literally a dependency.
>>
>>>
>>> 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?)
>>>
>>
>> This is an identical problem to #1. An option does *not* introduce any
>> indirection. Swift will however allow the following:
>>
>> struct First {
>> let item: [First]
>> }
>>
>> This is because `Array<T>`—if you look at its declaration—does not
>> *directly* store any type `T`. Instead, it stores a pointer to a buffer
>> holding `T`s, allocated at runtime. These semantics may be a big confusing
>> at first, but this is the tradeoff for the better performance value types
>> can sometimes bring.
>>
>>>
>>> 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.
>>>
>>
>> This is not a bug IMO. It is not the compiler’s job to prevent you from
>> compiling code that includes a type that cannot be instantiated.
>>
>> Unlike the previous cases, the compiler actually *can* generate code for
>> these types. You _could_ even unsafely instantiate these types. In the
>> previous cases, the compiler could not compute the size of the types.
>>
>>>
>>> 5. Similarly to case #4, Swift shouldn’t compile this:
>>>
>>> indirect enum First {
>>> case item(First)
>>> }
>>>
>>
>> Ditto #4.
>>
>>>
>>> 6. Cases #4 #5 could be written like case #2, and should also raise
>>> compilation errors.
>>>
>>
>> Ditto #4.
>>
>>>
>>> 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
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> I hope I was able to clear up your confusion. Let me know if you have any
>> other questions.
>>
>> Cheers,
>> Jaden Geller
>>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
