> This may be better suited to swift-evolution or users list, but regarding
> fatalError do you have any techniques for testing this behavior?
I believe the Swift compiler’s tests run code it expects to trap in a separate
process and verify that the other process trapped. We may want to think ab
> On Dec 11, 2015, at 1:02 PM, Dan Thorpe wrote:
>
> Thanks for the clarification Tony - and for reminding me of the primary goal
> r.e. API compatibility. :)
>
> This may be better suited to swift-evolution or users list, but regarding
> fatalError do you have any techniques for testing this
Thanks for the clarification Tony - and for reminding me of the primary goal
r.e. API compatibility. :)
This may be better suited to swift-evolution or users list, but regarding
fatalError do you have any techniques for testing this behavior? I was thinking
about an internal try/throw/ layer (w
Hi Dan, Florian,
I agree with Philippe that NSDecimal is a particularly troublesome area in
terms of how poorly the API is imported into Swift.
Since NSDecimal is already a value type, it may be possible to do something
better here ourselves without worrying about the bridging problem. It would
This thread is related to the thread I started last night about Foundation and
value types.
Ideally all Foundation types that are already structs would expose a more
Swifty interface and those that are naturally value types but currently
implemented as classes would be bridged and exposed in S
Hi all,
Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would
like to help and have a few questions on how to best tackle this.
I think it’s best to start with NSDecimal and then use NSDecimal to create
NSDecimalNumber. That’s why I want to concentrate on NSDecimal firs
