Oh, I see what you mean. I considered polymorphic types to be class hierarchies, when you're talking about ErrorType polymorphism.
Yes, I think that the compiler should be aware of what the function can throw, but I would be happier if it stayed a bit inconvenient to use reference types. > Le 18 déc. 2015 à 12:17:06, Félix Cloutier via swift-evolution > <[email protected]> a écrit : > > I'm not sure I understand your comment either. If I understand correctly, you > say that the problem I describe is applicable only to polymorphic types > (which is true). However, you then say that the only option today is > polymorphic error types. Isn't that an issue? (Also, why is it the only > option today?) > >> Le 18 déc. 2015 à 11:58:44, David Owens II <[email protected]> a écrit : >> >> >>> On Dec 18, 2015, at 7:03 AM, Félix Cloutier <[email protected]> wrote: >>> >>> For this reason, I don't like to encourage throwing polymorphic types, and >>> I think that it's a misconception to pretend that having a single type in >>> the throws annotation ensures that the function throws a single type. In my >>> opinion, the fact that it's currently possible but awkward to use >>> polymorphic types as errors is exactly as much support as the feature >>> should receive. >> >> I don’t follow this. Declaring a type that is an enum or a struct absolutely >> guarantees that the function only returns a single type. If the type is a >> class-based error, then sure, there’s not guarantee. >> >> However, the only option today is polymorphic error types. >> >> -David >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
