> On Dec 7, 2015, at 5:24 PM, David Hart wrote:
>
> You enable assertions for release builds then?
It depends on the target. In a lot of app-level code it doesn’t make much
difference to leave them in, while in lower-level performance-sensitive code
it’s a big slowdown. (Back when I worked at
precondition() is enabled for release builds.
On Mon, Dec 7, 2015 at 5:24 PM, David Hart via swift-users <
swift-users@swift.org> wrote:
> You enable assertions for release builds then? Remember, I'm talking
> specifically about library code: the same way that calling NSArray's
> objectAtIndex th
> On Dec 7, 2015, at 11:39 AM, Jan Neumüller via swift-users
> wrote:
>
> I fail to see any overhead here. Its the absolute minimum to get checked
> values. Anything less is not checking.
There’s no overhead if the function already ‘throws’ / returns errors. But not
all functions do that (an
> On 07.12.2015, at 20:03, Jens Alfke wrote:
>
>
>> On Dec 7, 2015, at 10:56 AM, Jan Neumüller via swift-users
>> mailto:swift-users@swift.org>> wrote:
>>
>> But what overhead? As you know Swift has *NO* exceptions. It’s just syntax
>> sugar for normale error values.
>
> Mostly the overhead
> On Dec 7, 2015, at 9:40 AM, Dmitri Gribenko wrote:
>
> There are
> just two processes -- one is performing a trap, and another one is the
> test harness that verifies that the other process terminated.
Ah — I thought it was some type of in-process exception/signal handler.
> What would you l
On Mon, Dec 7, 2015 at 10:02 AM, Jens Alfke wrote:
>
> On Dec 7, 2015, at 9:40 AM, Dmitri Gribenko wrote:
>
> There are
> just two processes -- one is performing a trap, and another one is the
> test harness that verifies that the other process terminated.
>
>
> Ah — I thought it was some type of
On Mon, Dec 7, 2015 at 9:25 AM, Jens Alfke wrote:
>
> On Dec 7, 2015, at 9:21 AM, Dmitri Gribenko wrote:
>
> Yes you can. Maybe not with the current XCTest, but there's nothing that
> prevents unit-testing traps in principle. The standard library is already
> doing that. See test/1_stdlib/Arra
> On Dec 7, 2015, at 9:21 AM, Dmitri Gribenko wrote:
>
> Yes you can. Maybe not with the current XCTest, but there's nothing that
> prevents unit-testing traps in principle. The standard library is already
> doing that. See test/1_stdlib/ArrayTraps.swift.gyb for some examples:
Nice! But co
Say for a moment we wanted to capture every such constraint at type
level -- with types NonEmptyString and PositiveNonZeroInteger. Would
these be declared as structs in Swift?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mail
I’m looking at the special case of library code. If I surface an API in a
library, it’s the library user who will call this function. Would you regard
this as an assert or throws scenario?
> On 07 Dec 2015, at 08:25, Brent Royal-Gordon via swift-users
> wrote:
>
>> When writing library code,
> On Dec 6, 2015, at 12:49 PM, David Hart via swift-users
> wrote:
>
> When writing library code, what method of parameter validation would be
> suggested?
Definitely assert. Assert is for illegal calls, i.e. programmer errors, while
errors (throw) are for valid runtime error conditions.
>
11 matches
Mail list logo
