Hi everyone,
With the release of swift 3, The interface to libDispatch has evolved quite a
lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using
"dispatch_queue_get_label(DIS
Hi guys,
It would be awesome if with this evolution, we could also auto-write equality
operators for enum with equatable payloads.
Today, considering this enum
enum SimpleEnum {
case case1
case case2
}
the condition SimpleEnum.case1 == SimpleEnum.case1 compiles and return true.
But if the
Summary
The aim of this proposal is to offer a new syntax to ease some uses of enums
with payload.
Situation to improve:
Enums makes it possible to have explicate typing where it was not possible
before. A classic example of that is filling a dictionary with data coming from
a file or a stream
t; Because it forces me to think about the bailout case(s) and is really not
> that much longer than your proposed syntax
>
> guard let book = case? .dict(inputData),
> let author = case? .dict(book?["author”]),
> let age = case? .integer(author?[&q
Well, that is a big big piece of news !
I want to thank you a lot for all you did on that project Chris.
I consider Swift is the smartest and greatest project that came out of Apple
those last years.
Smartest because it feel like this is one of the few project of the company
that actually kept i
Hi everybody,
I do agree with Kevin : trailing closures is only a possibility offered by the
language, you are not forced to use it.
In the case you show, I agree that the second syntax is more readable than the
first one. Good news is : it does compile :-).
I think adding a specific keyword or
It is true that testing an assert is not really possible, as it basically
crashes the app.
But we have to take into account that the behaviour of the assert method is not
strait-forward : it depends on what is the optimisation level. Here is an
extract of the inline doc of the assert method :
Hi guys,
I am part of the people mentioned in "Preserve exhaustiveness diagnostics for
non-exhaustive enums" : I see the completeness check as a major feature of
enums, that makes a difference between it and a list of constants in multiple
cases.
So much that in the coding rules of the company
I believe it will be prettyhard to find a solution that fits everyone’s
workflow and habits considering the size of the community.
The chance we have is that communication systems tends to be very flexible
nowadays.
Can we imagine some way to have multiple supports integrated ?
I can see tools l
