citely tells us that this method is
> optional and was not introduces in the A protocol itself
>
> func a() {..} // default implementation for "existed" method in A protocol
> }
>
> On 09.05.2016 19:15, Carlos Rodríguez Domínguez via swift-evolution wrote:
>> Rationale:
Rationale:
As a everybody knows, “optional” keyword is present in swift solely to maintain
compatibility with objective-c protocols. Optional methods in protocols are
neither a swift capability, nor a wanted one. In fact, proposal [0070] intends
to begin the transition to an optionals-free
re Clang-side
> annotations to improve the mapping of C/Objective-C APIs into Swift, it’s
> becoming more likely that API notes could/should grow into a more general
> mechanism for adapting existing C/Objective-C APIs to Swift without manually
> wrapping everything.
>
> -
That’s a really good syntax. Maybe the new @preferred could complete the
current @available, by also providing fix-it support. Note that it should be
enforced to have “compatible” parameters and return types between the old-style
func and the preferred one, as opposed to the current @available,
Well, it might be both an external annotation on C code and something specific
within swift. The first is interesting when you have access to the C source
code, but the later is good if you either don’t have access to the C source
code, or the code (swift, objective-c, C, etc.) is autogenerated
Yes, exactly, that’s a great summary of the proposal!
> El 25 mar 2016, a las 12:25, Haravikk <swift-evolut...@haravikk.me> escribió:
>
>
>> On 25 Mar 2016, at 09:56, Carlos Rodríguez Domínguez via swift-evolution
>> <swift-evolution@swift.org> wrote
rawValue: rank) else {
> return nil
> }
> self.suit = suit
> self.rank = rank
> }
> }
>
> let firstCard = Card(suit: 0, rank: 3)
> let secondCard = Card(suit: 3, rank: 2)
> firstCard?.rank // returns Four
> secondCard?.suit // returns Clubs
>
