@Howard
I was thinking the same about the constraint.
Does that mean that Never should be a subtype of Error (maybe it is already) ?
Else you couldn't say throws(Never) or FSTore
@Howard
I'm not sure about <>, it should stay reserved for generics, IMHO.
Pierre
> Le 13 janv. 2017 à 01:11, Howar
@Slava,
I'm imagining that the compiler does much the same as Anton suggested, e.g.
Anton's:
struct FStore {
let f: () throws -> Void
init(_ f: @escaping () throws -> Void) { self.f = f }
func call() throws { try f() }
}
Is much the same as my:
struct FStore
@Anton, Yes that would work and we would get typed throws, which I like. As
an aside, I think E would have to be constrained to be an Error, ``, and maybe `throws` reads better because you are used to types
in angle brackets.
-- Howard.
On 13 January 2017 at 08:32, Anton Zhilin wrote:
> The b
> On Jan 11, 2017, at 2:02 PM, Howard Lovatt via swift-evolution
> wrote:
>
> Another possibility, other than generics, would be to drop rethrows all
> together and have the compiler infer if a throw is possible or not, including:
>
> struct FStore {
> let f: () throws -> Void
>
The best way to deal with such situations should be typed throws. Then
rethrows should be removed and replaced with generics in throws clause. E
== Never ⇔ function does not throw.
struct FStore {
let f: () throws(E) -> Void
init(_ f: @escaping () throws(E) -> Void) { self.f = f }
func
