I suggest using an enum to represent success and failure. It's usually
referred to as `Result`. It might seem weird for the closure that you
presented as an example, since it would be Result, but it properly
captures the possibility of having thrown.
``` swift
enum UselessError : Swift.Error {
I stand corrected.
I do/did think that there is a difference in the way it handles pointers
optionals and other optionals, but I now realise that even that could not be
the case.
So please ignore the last line in my previous post.
The rest still stand ;-)
Regards,
Rien
Site: http://balancingr
> On Jan 9, 2017, at 11:19 PM, Rien via swift-users
> wrote:
>
> It means that a call to that function with an optional will unwrap the
> optional before it is used.
>
> That is quite neat when dealing with C-API’s because often you will receive a
> pointer from a C-function which is optiona
Perhaps the optimizer unrolls the inner loop, and thus can skip safety checks.
Naively, seems trickier to do for the iterator.
> El ene. 4, 2017, a las 9:10 PM, Jens Persson via swift-users
> escribió:
>
> I noticed disabling safety checks made the custom Iterator as fast as the two
> nested
> On Jan 9, 2017, at 11:59 PM, Pierre Monod-Broca via swift-users
> wrote:
>
> Hi again,
>
> You might want to look at Self requirement in protocols for exemple:
> protocol P {
> func items(/*...*/) -> [Self]
> }
> class C: P {
> func items(/*...*/) -> [C] {
>...
> }
> }
FWIW, this req
Hi again,
You might want to look at Self requirement in protocols for exemple:
protocol P {
func items(/*...*/) -> [Self]
}
class C: P {
func items(/*...*/) -> [C] {
...
}
}
However it might not always work as you expect.
I can't say which is the better. Using associated type might be
