[swift-evolution] Make integer conversion initializers failable

[Javier Soto]

I'm curious: how would you use the failable initializers? I feel like, more
often than not, you would end up force-unwrapping the return value, which
would produce the same result as trapping inside. But I guess in that case
you would make it clearer on the caller site that that can fail?
On Fri, Feb 12, 2016 at 9:23 AM Félix Cloutier <swift-evolution at swift.org>
wrote:

> It appears that the current integer conversion initializers will either
> always work, possibly trap, or truncate:
>
> init(_: Int)
> init(_: Int8)
> init(_: Int16)
> init(_: Int32)
> init(_: Int64)
> init(_: UInt)
> init(_: UInt8)
> init(_: UInt16)
> init(_: UInt32)
> init(_: UInt64)
> init(truncatingBitPattern: Int)
> init(truncatingBitPattern: Int16)
> init(truncatingBitPattern: Int32)
> init(truncatingBitPattern: Int64)
> init(truncatingBitPattern: UInt)
> init(truncatingBitPattern: UInt16)
> init(truncatingBitPattern: UInt32)
> init(truncatingBitPattern: UInt64)
>
>
> I suggest that we change trapping initializers to failable initializers.
> Initializers that can't fail (identity, unsigned -> bigger signed/unsigned,
> signed -> bigger signed) should keep a non-Optional type.
>
> This could extend to changing SignedIntegerType's and
> UnsignedIntegerType's (U)IntMax to failable initializers as well.
>
> I think I remember someone on the core team saying that someone's working
> on integer types at the moment. Is that right?
>
> Félix
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/1cbd1c8a/attachment.html>