Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Javier Soto via swift-evolution]

What doesn't happen today? The issue is not when they ship a new SDK: When
rebuilding your app against it, you'll get a warning for a missing case.
The problem is when running the app against a newer iOS version with a
newer version of the SDK where the enum has a new case.
On Sat, Jan 6, 2018 at 3:10 PM Jon Shier  wrote:

> Except it clearly doesn’t happen today when Apple ships new SDKs.
> Obviously there’s an alternate mechanism used in that case. I’m just
> curious what it is and why Swift so desperately needs an alternative.
>
>
> Jon
>
> On Jan 6, 2018, at 5:49 PM, Javier Soto  wrote:
>
> This is very much an issue in Obj-C today. If you have an NS_ENUM defined
> with cases A, B, and C, this switch is correct:
>
> int foo;
> swith (e) {
> case A: foo = 0; break;
> case B: foo = 1; break;
> case C: foo = 2; break;
> }
>
> (Note the lack of a default case)
>
> If that enum is defined in a framework and it changes after the app is
> compiled (like it's the case with Apple frameworks), then that code
> produces no warning, yet the foo variable will have a garbage value
> (undefined behavior, but as far as the compiler can tell at compile time
> your code is fine)
>
> Adding a default clause to that switch has the downside of not getting
> warnings for new added cases, like has been discussed before, which is very
> useful.
> On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> At this point I think it might be useful to outline how binary
>> compatibility works for Objective-C on Apple platforms right now. As an app
>> developer I’m not intimately familiar with what happens when you run an app
>> compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to
>> call old code paths or something else? The more this thread goes on the
>> more confused I get about why Swift would have this issue while it doesn’t
>> appear to be one for Obj-C. If an enum adds a case now, I don’t have to
>> care until I recompile using the new SDK. Is the intention for Swift to be
>> different in this regard?
>>
>>
>>
>> Jon Shier
>>
>> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Is it hard to imagine that most everyone can get what they want and keep
>> the syntax clean and streamlined at the same time? Without any "@" signs or
>> other compiler hints?
>>
>>
>> For what it's worth, the original version of the proposal started with a
>> modifier (a context-sensitive keyword, like 'final'), but the core team
>> felt that there were a lot of modifiers in the language already, and this
>> didn't meet the bar.
>>
>>
>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add
>>> new cases without breaking binaries compiled against previous versions"
>>
>>
>> When an enum changes, and the change causes the code to break, the user
>> can be presented with migration options from an automated IDE tool. In what
>> specific way does this not solve the issue about having to upgrade your
>> code when using someone else's code library? This very notion implies your
>> disgruntled about doing work when things are upgraded, is that really what
>> this fuss is all about?
>>
>> A well written language interpreter and auto-tooling IDE would not need
>> hints embedded in the code syntax itself. Migration hints from version to
>> version should not be a part of either the past or future version of the
>> code library.
>>
>>
>> Thanks for bringing this up! Unfortunately, it falls down in practice,
>> because if there's a new enum case, *it's unclear what you want to do
>> with it.* If you're handling errors, it's not obvious that the way
>> you've handled any of the *other* errors is appropriate. In the
>> (admittedly controversial) SKPaymentTransactionState case, none of the
>> existing code would be appropriate to handle the newly-introduced
>> "deferred" case, and nor could StoreKit provide "template" code that would
>> be appropriate to the client app.
>>
>>
>> In any case, though, the key point on this particular quoted sentence is
>> "without breaking *binaries"*. Any such change must be valid *without* 
>> recompilation,
>> and indeed without any intervention from the developer or an IDE, because
>> that's what happens when the user updates their OS.
>>
>> Jordan
>>
>>
>>
>>
>> ...
>>
>> I don't expect the community to agree on language grammar, but the common
>> sense here on how to achieve the intended goals seems to be out of wack.
>>
>> If someone can present a clear logical statement as to how an automated
>> migration tool behind the scenes in the IDE to handle all your versioning
>> worries, does not make this whole discussion about adding more convoluted
>> syntax additions irrelevant, I'd love to hear it.
>>
>> ___
>>
>> 

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Javier Soto via swift-evolution]

This is very much an issue in Obj-C today. If you have an NS_ENUM defined
with cases A, B, and C, this switch is correct:

int foo;
swith (e) {
case A: foo = 0; break;
case B: foo = 1; break;
case C: foo = 2; break;
}

(Note the lack of a default case)

If that enum is defined in a framework and it changes after the app is
compiled (like it's the case with Apple frameworks), then that code
produces no warning, yet the foo variable will have a garbage value
(undefined behavior, but as far as the compiler can tell at compile time
your code is fine)

Adding a default clause to that switch has the downside of not getting
warnings for new added cases, like has been discussed before, which is very
useful.
On Fri, Jan 5, 2018 at 7:11 PM Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> At this point I think it might be useful to outline how binary
> compatibility works for Objective-C on Apple platforms right now. As an app
> developer I’m not intimately familiar with what happens when you run an app
> compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to
> call old code paths or something else? The more this thread goes on the
> more confused I get about why Swift would have this issue while it doesn’t
> appear to be one for Obj-C. If an enum adds a case now, I don’t have to
> care until I recompile using the new SDK. Is the intention for Swift to be
> different in this regard?
>
>
>
> Jon Shier
>
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is it hard to imagine that most everyone can get what they want and keep
> the syntax clean and streamlined at the same time? Without any "@" signs or
> other compiler hints?
>
>
> For what it's worth, the original version of the proposal started with a
> modifier (a context-sensitive keyword, like 'final'), but the core team
> felt that there were a lot of modifiers in the language already, and this
> didn't meet the bar.
>
>
> "Rather, we are how to enable the vendor of a nonexhaustive enum to add
>> new cases without breaking binaries compiled against previous versions"
>
>
> When an enum changes, and the change causes the code to break, the user
> can be presented with migration options from an automated IDE tool. In what
> specific way does this not solve the issue about having to upgrade your
> code when using someone else's code library? This very notion implies your
> disgruntled about doing work when things are upgraded, is that really what
> this fuss is all about?
>
> A well written language interpreter and auto-tooling IDE would not need
> hints embedded in the code syntax itself. Migration hints from version to
> version should not be a part of either the past or future version of the
> code library.
>
>
> Thanks for bringing this up! Unfortunately, it falls down in practice,
> because if there's a new enum case, *it's unclear what you want to do
> with it.* If you're handling errors, it's not obvious that the way you've
> handled any of the *other* errors is appropriate. In the (admittedly
> controversial) SKPaymentTransactionState case, none of the existing code
> would be appropriate to handle the newly-introduced "deferred" case, and
> nor could StoreKit provide "template" code that would be appropriate to the
> client app.
>
>
> In any case, though, the key point on this particular quoted sentence is
> "without breaking *binaries"*. Any such change must be valid *without* 
> recompilation,
> and indeed without any intervention from the developer or an IDE, because
> that's what happens when the user updates their OS.
>
> Jordan
>
>
>
>
> ...
>
> I don't expect the community to agree on language grammar, but the common
> sense here on how to achieve the intended goals seems to be out of wack.
>
> If someone can present a clear logical statement as to how an automated
> migration tool behind the scenes in the IDE to handle all your versioning
> worries, does not make this whole discussion about adding more convoluted
> syntax additions irrelevant, I'd love to hear it.
>
> ___
>
> Sincerely,
> Jason
>
>
>
>
>
>
> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu  wrote:
>
>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I think this whole thing has been unnecessarily convoluted. As a result,
>>> the majority of the replies are rabbit holes.
>>>
>>> In my opinion, the true root of the concept in question is as follows:
>>>
>>> *A list of something is desired:*
>>> 1 - Pancake
>>> 2 - Waffle
>>> 3 - Juice
>>>
>>> *Developer wishes to be able to:*
>>> *A)* Add new things to the list of choices in the future as they come
>>> up with new ideas
>>> *B)* Sometimes select one of the choices to be chosen as the normal
>>> choice if no choice is made by the user
>>>
>>> A 

Re: [swift-evolution] [Pitch] #error

[Javier Soto via swift-evolution]

+1 on adding a compile-time error directive. #error seems like the right
syntax as well.
I had a maybe nit-picky comment about the proposal though. I think the
example may not be ideal, since you could accomplish that compile-time
error by annotating the method or class where that code lives with
@available(tvOS) , no?
On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution <
swift-evolution@swift.org> wrote:

> This is the best I've found for searching the archives:
> https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22
>
>
>
> On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
>> >
>> > Daryle, there have been several pitches in the past with respect to
>> #error, and very enlightening arguments both for and against the idea have
>> been eloquently written.
>> >
>> > Since you’re resurrecting this idea, could I suggest going back through
>> the archives and linking to and summarizing these arguments, so that we’re
>> not restarting the discussion from scratch? :)
>>
>> Is there somewhere to search the archives?
>>
>> —
>> Daryle Walker
>> Mac, Internet, and Video Game Junkie
>> darylew AT mac DOT com
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

[Javier Soto via swift-evolution]

Based on your examples I think you were thinking about the "guard" keyword,
instead of "if"?

`If let foo = bar else` is not a valid construction. `if let foo = bar { }
else {}` may have been what you meant, but in this case it is clear that
this is just like a regular if, combined with unwrapping an optional.
On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 from me, I think that it makes perfect sense the way it is.
>
> More specifically, I read `if let safe = optional` as "if optional can be
> unwrapped into safe, then ..."
> I think `obtain let` is more confusing, as it's not clear that it's a
> conditional from that keyword. Plus to me, "obtain" seems like it would be
> getting something from somewhere else, not always locally, maybe use an
> `unwrap` keyword in there somewhere, if you want it to be very clear what's
> happening?
>
> -thislooksfun (tlf)
>
> On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> Here’s a draft proposal to change *if let* construction for *obtain let*. 
> Proposal is at:
>
> https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/-Use-obtain-let-instead-if-let-constructions.md
>
> I would like to see what you think and get help with "*Effect on ABI 
> stability*" and "*Effect on API resilience*" points
>
> Carlos
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

[Javier Soto via swift-evolution]

My biggest issue with Optional conforming to Comparable is that while a
default implementation may sometimes be useful, it may not necessarily be
the one you want. In that last example with lastName, if you wanted to
change the policy for whether users without last name appear first or last,
you'd have to write more verbose code anyway. Generally, reading that code
with just "<" I would never remember what Swift would do with nil (do they
go first or last?)

If you don't care that much, a simple one-liner without all those guards
could also be:

users.sorted { ($0.lastName ?? "") < ($1.lastName ?? "") }
On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> I have personally (ab)used this for the following:
>
> class User {
> var email: String
> var firstName: String?
> var lastName: String?
> }
>
> You have a list of users based on email, so last name is optional. In
> Swift 2.x, you can do:
>
> users.sort({ $0.lastName < $1.lastName })
>
> Now, you need to do:
>
> users.sorted({
> guard let firstName = $0.0.lastName else {
> return true
> }
>
> guard let secondName = $0.1.lastName else {
> return false
> }
>
> return firstName < secondName
> })
>
> Which aside from being a brain teaser how to properly maintain ordering
> when $0.0's lastName != nil && $0.1's lastName == nil, adds additional few
> lines.
>
> But I agree that it may come as confusing with Ints, etc. - with strings
> it kind of makes sense since nil is like an empty string which is placed in
> front of everything.
>
> On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This change is going to have a HUGE impact for me. I use this sort of
> comparison _all the time_ and find it incredibly useful, and have had
> literally zero bugs caused by this. Surely I can't be the only one who uses
> this. I am not looking forward to copying & pasting a reimplementation of
> the comparison functions into every single project I work on.
>
>
> Can you give some examples as to how this will have such a huge impact?
> Now that we have the ?? operator it seems that this is fairly easy to
> replace:
>
> value < 5 // where value is of type Int?
>
> With:
>
> (value ?? 0) < 5
>
>
> The latter is completely clear what the behaviour of nil is.
>
> Also, you can still re-add the operators where you need them, ideally with
> as limited a type as possible so you can make sure that it's behaviour is
> well defined.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Throws, rethrows and declaration-modifiers in function declarations

[Javier Soto via swift-evolution]

I see where you're coming from.
Without any actual insight into the design of this syntax, I think throws
is in the position it is because it relates more to the return type of the
function. Aka a `throws -> T` function can either throw ErrorProtocol OR
return a T value.
On Tue, Jul 19, 2016 at 10:51 AM Matthieu Oger via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello,
>
> I'm currently reading the updated Swift 3 preview book, and was wondering
> about the `throws` and `rethrows` keywords.
>
> In a function declaration, all the keywords are at the beginning, except
> for `throws` and `rethrows`, which are… oddly placed.
>
> In the grammar:
>
> ```
>
> *function-declaration *→ *function-head
> 
>  ­function-name
> ­
>  **generic-parameter-clause
> ­*
> opt­*function-signature
> ­
>  **function-body
> ­*
> opt­
>
> *function-head *→ *attributes
> ­*
> opt­*declaration-modifiers
> ­*
> opt­func­
>
> *function-signature *→ *parameter-clause
> ­*
> throws­opt­*function-result
> ­*
> opt­
>
> *function-signature *→ *parameter-clause
> ­*
> rethrows­*function-result
> ­*
> opt­
>
> ```
> Is there a reason to have throws and rethrows at this specific position,
> instead of declaration-modifiers?
>
> ie.:
>
> This:
>
> ```
> func send() throws -> String {}
> ```
>
> Becomes:
>
> ```
> throwing func send() -> String {}
> rethrowing func send() -> String {}
> ```
>
> Like:
>
> ```
> mutating func send() -> String {}
> ```
>
> Or:
>
> ```
> throw func send() -> String {}
> rethrow func send() -> String {}
> ```
>
> Like:
>
> ```
> override func send() -> String {}
> ```
>
> (You can also see the weird difference between `override` and `mutating`,
> one using the -ing suffix, the other being infinitive)
>
> Am I missing something? I find that these keywords break the flow of the
> function declaration, separating the parameters and the return type, which
> is never done anywhere else.
>
> Thanks.
>
> --
> Matthieu Oger
> Pixelnest Studio 
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Sealed classes by default

[Javier Soto via swift-evolution]

IMO the issue with the argument that we wouldn't be able to "monkey patch"
things on sealed classes is that that is already the nature of Swift. The
designer of an API can choose to use structs instead of classes, and then
there's already no way to "subclass". Moreover, "final" already exists, and
whether sealed is introduced or not, and whether it becomes the default or
not, API designers are already free to use final in all classes they do not
intend to be subclassed, so I think that would be an argument against final
existing in the first place, and that ship has already sailed.

As for whether sealed would allow for optimizations: my hunch is that it
would. However, as I write this I noticed a flaw with my proposal: I said
that sealed classes would be exported as final. This is only half-true.
They would in that they can't be subclassed outside the module, but there
could be subclasses in the same module! That means if the parent were to be
treated as final, code outside the module would incorrectly devirtualize
non-final methods.
On Tue, Jun 28, 2016 at 7:59 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>>
> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> -1 for the fact that if all devs can write working code, fewer can do
> it in a clear structured fashion that is well designed for extensibility.
> >>
> >> This sounds more like an argument for having sealed classes than not.
> As the proposal points out in the motivation, if the base class is not
> designed with subclassing in mind then overriding methods can result in
> unintended behavior (e.g. crashing, or other bugs).
> >
> > But I think the counter argument is, what if you need to fix or
> workaround unintended behavior of the class you’re trying to use?
>
> Typically you modify something open source - 99% of which is on GitHub.
> IMHO the best way is to either fork it and perhaps submit a pull request
> with the fix.
>
> But I understand that this is not always possible...
>
>
> >
> > l8r
> > Sean
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Sealed classes by default

[Javier Soto via swift-evolution]

That is a very good point, it should be explicitly mentioned in the
proposal. My thought would be that since in the Obj-C runtime it's not
possible to guarantee a class won't have subclasses, or that a method is
not overriden, Obj-C classes would be imported as open.

On the Swift side, I think today it's possible to declare a "public final
@objc class", but you can still inherit from it from Obj-C, right? My hunch
would be that that should be disallowed, but perhaps there's a reason why
it's allowed today.
On Mon, Jun 27, 2016 at 4:25 PM Michael Ilseman <milse...@apple.com> wrote:

> Could you elaborate on how we should treat classes imported from
> Objective-C or CF-style C? That is, do we always annotate them as being
> “open” because those paradigms permit subclassing anywhere, or do you
> propose some kind of recommended “sealed” audit, or what?
>
> On Jun 27, 2016, at 3:40 PM, Javier Soto via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello!
>
> I sent this as a PR <https://github.com/apple/swift-evolution/pull/376>
> on the swift-evolution repo, but we never had any discussion about it
> on-list, besides a long time ago
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/9702/focus=9708>.
> Here's the first draft of the proposal:
>
>
> Sealed classes by default
> <https://github.com/JaviSoto/swift-evolution/blob/a46877afb0302d2b03fa493255f5ced04ccb7f34/proposals/-sealed-by-default.md#introduction>
> Introduction
>
> Introduce a new sealed class modifier that makes classes and methods final
>  outside of the module they're declared in, but non-final within the
> module.
>
> <https://github.com/JaviSoto/swift-evolution/blob/a46877afb0302d2b03fa493255f5ced04ccb7f34/proposals/-sealed-by-default.md#motivation>
> Motivation
>
>- It is not uncommon to have a need for a reference type without
>needing inheritance. Classes must be intentionally designed to be
>subclassable, carefully deciding which methods are the override
>entry-points such that the the behavior remains correct and subclasses
>respect the Liskov substitution principle
><https://en.wikipedia.org/wiki/Liskov_substitution_principle>.
>- Defaulting to non-final allows the author of a class to accidentally
>leave the visible methods open for overrides, even if they didn't carefully
>consider this possibility.
>- Requiring that the author of a class mark a class as open is akin to
>requiring symbols to be explicitly public: it ensures that a conscious
>decision is made regarding whether the ability to subclass a class is
>part of the API.
>
>
> <https://github.com/JaviSoto/swift-evolution/blob/a46877afb0302d2b03fa493255f5ced04ccb7f34/proposals/-sealed-by-default.md#proposed-solution>Proposed
> solution
>
>- New sealed (*actual name pending bike-shedding*) class modifier for
>classes and methods which marks them as only overridable within the module
>they're declared in.
>- sealed becomes the default for classes and methods.
>- New open (*actual name pending bike-shedding*) class modifier to
>explicitly mark a class or a method as overridable.
>
>
> <https://github.com/JaviSoto/swift-evolution/blob/a46877afb0302d2b03fa493255f5ced04ccb7f34/proposals/-sealed-by-default.md#detailed-design>Detailed
> design
>
> Code Examples:
>
> /// ModuleA:
> /// This class is `sealed` by default./// This is equivalent to `sealed class 
> SealedParentClass`class SealedParentClass {
> /// This method is `sealed` by default`.
> func foo()
>
> /// This raises a compilation error: a method can't have a 
> "subclassability"
> /// level higher than that of its class.
> open func bar()
>
> /// The behavior of `final` methods remains unchanged.
> final func baz()
> }
>
> open class OpenParentClass {
> /// This method is `sealed` by default`.
> func foo()
>
> /// Overridable methods in an `open` class must be explicitly marked as 
> `open`.
> open func bar()
>
> /// The behavior of a `final` method remains unchanged.
> final func baz()
> }
> /// The behavior of `final` classes remains unchanged.final class FinalClass 
> { }
>
> /// ModuleB:
> import ModuleA
> /// This raises a compilation error: ParentClass is effectively `final` 
> from/// this module's point of view.class SubclassA : SealedParentClass { }
> /// This is allowed since `OpenParentClass` has been marked explicitly 
> `open`class SubclassB : OpenParentClass {
> /// This raises a compilation error: `OpenParentClass.foo` is
> /// effectively `final` outside of `ModuleA`.
> over

[swift-evolution] [Proposal] Sealed classes by default

[Javier Soto via swift-evolution]

Hello!

I sent this as a PR  on
the swift-evolution repo, but we never had any discussion about it on-list,
besides a long time ago
.
Here's the first draft of the proposal:


Sealed classes by default

Introduction

Introduce a new sealed class modifier that makes classes and methods
final outside
of the module they're declared in, but non-final within the module.

Motivation

   - It is not uncommon to have a need for a reference type without needing
   inheritance. Classes must be intentionally designed to be subclassable,
   carefully deciding which methods are the override entry-points such that
   the the behavior remains correct and subclasses respect the Liskov
   substitution principle
   .
   - Defaulting to non-final allows the author of a class to accidentally
   leave the visible methods open for overrides, even if they didn't carefully
   consider this possibility.
   - Requiring that the author of a class mark a class as open is akin to
   requiring symbols to be explicitly public: it ensures that a conscious
   decision is made regarding whether the ability to subclass a class is
   part of the API.

Proposed
solution

   - New sealed (*actual name pending bike-shedding*) class modifier for
   classes and methods which marks them as only overridable within the module
   they're declared in.
   - sealed becomes the default for classes and methods.
   - New open (*actual name pending bike-shedding*) class modifier to
   explicitly mark a class or a method as overridable.

Detailed
design

Code Examples:

/// ModuleA:
/// This class is `sealed` by default./// This is equivalent to
`sealed class SealedParentClass`class SealedParentClass {
/// This method is `sealed` by default`.
func foo()

/// This raises a compilation error: a method can't have a "subclassability"
/// level higher than that of its class.
open func bar()

/// The behavior of `final` methods remains unchanged.
final func baz()
}

open class OpenParentClass {
/// This method is `sealed` by default`.
func foo()

/// Overridable methods in an `open` class must be explicitly
marked as `open`.
open func bar()

/// The behavior of a `final` method remains unchanged.
final func baz()
}
/// The behavior of `final` classes remains unchanged.final class FinalClass { }

/// ModuleB:
import ModuleA
/// This raises a compilation error: ParentClass is effectively
`final` from/// this module's point of view.class SubclassA :
SealedParentClass { }
/// This is allowed since `OpenParentClass` has been marked explicitly
`open`class SubclassB : OpenParentClass {
/// This raises a compilation error: `OpenParentClass.foo` is
/// effectively `final` outside of `ModuleA`.
override func foo() { }

/// This is allowed since `OpenParentClass.bar` is explicitly `open`.
override func bar() { }
}

Impact
on existing code

   - This would be a backwards-breaking change for all classes and methods
   that are public and non-final, which code outside of their module has
   overriden. Those classes/methods would fail to compile. Their superclass
   would need to be changed to open.

Alternatives
considered

   - Defaulting to final instead: This would be comparable to Swift
   defaulting to private, as opposed to internal. Just like internal is a
   better trade-off, sealed by default also makes sure that getting started
   with Swift, writing code within a module, doesn't require a lot of
   boilerplate, and fighting against the compiler.

-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3 vs "additive" proposals

[Javier Soto via swift-evolution]

Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the
proposal already: https://github.com/apple/swift-
evolution/pull/376
I would be happy to work with you on improving the proposal. I think your
mention to sealed protocols is super interesting, but I think that could be
additive. It might be easier to discuss each of them separately.

On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson 
wrote:

> On Jun 22, 2016, at 4:29 PM, Javier Soto  wrote:
>
> I'll work on a formal proposal for sealed by default :)
>
>
> I have already been planning a proposal for sealed (in general) but didn’t
> think it fit with the goals of Swift 3 anymore (I had forgotten about the
> plan to make sealed the default).
>
> John, the modifier you allude to would be to allow inheritance outside the
> module, correct?  Would it also be appropriate to introduce `sealed`-like
> behavior for protocols (no protocol inheritance and / or conformance
> outside the module) along side sealed by default or should that still wait
> as it is purely additive?
>
> The proposal(s) I am planning is intended to achieve exhaustive pattern
> matching for classes and protocols.
>
>
> On Wed, Jun 22, 2016 at 1:43 PM John McCall  wrote:
>
>> On Jun 22, 2016, at 1:38 PM, Matthew Johnson 
>> wrote:
>>
>> On Jun 22, 2016, at 11:48 AM, John McCall  wrote:
>>
>> On Jun 22, 2016, at 9:15 AM, Javier Soto  wrote:
>> How would we evaluate the proposal to introduce the "sealed" specifier
>> for classes (open within module, final outside of module) and default to
>> that, in terms of source-code compatibility?
>> From my point of view it might be easier to do before Swift 3, but if
>> delayed until Swift 4 it wouldn't be the most time-consuming breakage for
>> developers.
>>
>>
>> I believe we consider this plan of record, actually, other than the
>> spelling of the modifier.  It's something we probably ought to commit to in
>> Swift 3, though.
>>
>>
>> By “commit to in Swift 3” do you mean that it is likely the core team
>> would introduce a proposal for this in Swift 3?
>>
>>
>> We might be able to put the decision off as part of the larger resilience
>> feature, but I think it would be better to settle this in 3 if we can.
>> Who, exactly, authors the proposal is not settled; a community proposal
>> would be welcome.
>>
>> John.
>>
>>
>>
>> John.
>>
>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Jun 22, 2016, at 10:59 AM, John McCall  wrote:
>>>
>>>
>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>>- Rationalizing base conversion protocol names. I personally don't
>>>have the heart to try to re-address the "LiteralConvertible" protocol
>>>naming thing again but this would be the last chance to do anything about
>>>getting this issue addressed.
>>>
>>> Given the vast amount of bike shedding that has already happened around
>>> this topic, I don’t think there is a solution that everyone will be happy
>>> with.  It is also unclear (to me at least) what solution might be
>>> acceptable to the core team.
>>>
>>>
>>> To be clear, I don't care about the name.  If you want to rename
>>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the
>>> conversation into the muck again. :)  It's the design of the requirements
>>> that I'm pretty opposed to revisiting.
>>>
>>>
>>> This is orthogonal to the discussion that happened in your thread,
>>> definitely no discussion of any changes to the requirements. :)
>>>
>>> We are discussing this proposal:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>  and
>>> specifically the use of the `Convertible` suffix for both the
>>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible`
>>> protocols where the conversion runs in opposite directions.
>>>
>>> The core team decision was:
>>>
>>> "The feedback on the proposal was generally positive about the idea of
>>> renaming these protocols, but the specific names in the proposal are not
>>> well received, and there is no apparent confluence in the community on
>>> better names.  The core team prefers discussion to continue -- if/when
>>> there is a strong proposal for a better naming approach, we can reconsider
>>> renaming these."
>>>
>>>
>>> John.
>>>
>>>
>>> At the same time, it continues to bother me that `Convertible` is used
>>> by standard library protocols with two completely different meanings.  This
>>> is a problem that deserves to be solved and as it involves a breaking
>>> change Swift 3 is the right timeframe in which to do so.
>>>
>>> If the core team is able to indicate an approach they favor I would be
>>> willing to revise and resubmit the proposal. 

Re: [swift-evolution] Swift 3 vs "additive" proposals

[Javier Soto via swift-evolution]

I'll work on a formal proposal for sealed by default :)

On Wed, Jun 22, 2016 at 1:43 PM John McCall  wrote:

> On Jun 22, 2016, at 1:38 PM, Matthew Johnson 
> wrote:
>
> On Jun 22, 2016, at 11:48 AM, John McCall  wrote:
>
> On Jun 22, 2016, at 9:15 AM, Javier Soto  wrote:
> How would we evaluate the proposal to introduce the "sealed" specifier for
> classes (open within module, final outside of module) and default to that,
> in terms of source-code compatibility?
> From my point of view it might be easier to do before Swift 3, but if
> delayed until Swift 4 it wouldn't be the most time-consuming breakage for
> developers.
>
>
> I believe we consider this plan of record, actually, other than the
> spelling of the modifier.  It's something we probably ought to commit to in
> Swift 3, though.
>
>
> By “commit to in Swift 3” do you mean that it is likely the core team
> would introduce a proposal for this in Swift 3?
>
>
> We might be able to put the decision off as part of the larger resilience
> feature, but I think it would be better to settle this in 3 if we can.
> Who, exactly, authors the proposal is not settled; a community proposal
> would be welcome.
>
> John.
>
>
>
> John.
>
> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 22, 2016, at 10:59 AM, John McCall  wrote:
>>
>>
>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>- Rationalizing base conversion protocol names. I personally don't
>>have the heart to try to re-address the "LiteralConvertible" protocol
>>naming thing again but this would be the last chance to do anything about
>>getting this issue addressed.
>>
>> Given the vast amount of bike shedding that has already happened around
>> this topic, I don’t think there is a solution that everyone will be happy
>> with.  It is also unclear (to me at least) what solution might be
>> acceptable to the core team.
>>
>>
>> To be clear, I don't care about the name.  If you want to rename
>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the
>> conversation into the muck again. :)  It's the design of the requirements
>> that I'm pretty opposed to revisiting.
>>
>>
>> This is orthogonal to the discussion that happened in your thread,
>> definitely no discussion of any changes to the requirements. :)
>>
>> We are discussing this proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>  and
>> specifically the use of the `Convertible` suffix for both the
>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible`
>> protocols where the conversion runs in opposite directions.
>>
>> The core team decision was:
>>
>> "The feedback on the proposal was generally positive about the idea of
>> renaming these protocols, but the specific names in the proposal are not
>> well received, and there is no apparent confluence in the community on
>> better names.  The core team prefers discussion to continue -- if/when
>> there is a strong proposal for a better naming approach, we can reconsider
>> renaming these."
>>
>>
>> John.
>>
>>
>> At the same time, it continues to bother me that `Convertible` is used by
>> standard library protocols with two completely different meanings.  This is
>> a problem that deserves to be solved and as it involves a breaking change
>> Swift 3 is the right timeframe in which to do so.
>>
>> If the core team is able to indicate an approach they favor I would be
>> willing to revise and resubmit the proposal.  But I don’t want to spend any
>> further time speculating about what solution might be considered acceptable.
>>
>> Matthew
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Javier Soto
>
>
>
>
> --
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Javier Soto via swift-evolution]

I agree we could disallow explicitly declaring implicitly unwrapped
function parameters, but this will be needed for the clang importer since
there will still be many C and ObjC APIs not tagged for nullability.
On Wed, Jun 8, 2016 at 2:46 PM Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 I agree. Unwrapping in the functional signature is confusing for the
> user; many don’t realize that it puts the burden of checking on them.
> Non-optional function parameters make this explicit by preventing passing
> in Optional types, forcing the user to check, which they should be doing
> anyway.
>
> On Wed, Jun 8, 2016 at 12:22 PM J. Charles M. N. via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> This confused me at the beginning.
>>
>> But doesn't Int! In parameter type means the function is awaiting an
>> unwrapped value so the user should ensure that it data parameter is
>> available, valid, and unwrapped?
>>
>> --
>> J. Charles
>>
>> > Le 8 juin 2016 à 13:30, Spromicky via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >
>> > Hello, everyone!
>> >
>> > I wanna propose to you to remove force unwrapping in fuction signature
>> for swift code. That no sense in clear swift code. If we wanna use some
>> optional value as function param, that is not optional, we must unwrap it
>> before function call.
>> > People who new in swift look at how they old Obj-C code (without
>> nullability modifiers) translate in to swift:
>> >
>> > Obj-C:
>> > - (void)foo:(NSInteger)bar {
>> >//...
>> > }
>> >
>> > Swift transaliton:
>> > func foo(bar: Int!) {
>> >//...
>> > }
>> >
>> > And think that force unwrapping in signature is good practice. And
>> start write functions in clear swift code like this:
>> >
>> > func newFoo(bar: Int!) {
>> >//...
>> > }
>> >
>> > and use it like this:
>> >
>> > let bar: Int? = 1
>> > newFoo(bar)
>> >
>> > And it really work, and they does not think that this can crash in case
>> if `bar` will be `nil`.
>> > But in clear swift we wanna work with parametrs in function that
>> clearly or optional, or not.
>> >
>> > func newFoo(bar: Int) {
>> >//...
>> > }
>> >
>> > or
>> >
>> > func newFoo(bar: Int?) {
>> >//...
>> > }
>> >
>> > When we write a new function we know what we need in this case and use
>> optional params or not.
>> >
>> > So my proposal is remove force unwrapping(`!`) from function
>> signatures, cause it have no sense, and that confuse new users.
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

[Javier Soto via swift-evolution]

Hi David! No hard feelings at all :) I just wanted to propose something
different, dinner sounds great! Thanks for setting that google forms up!

On Tue, Jun 7, 2016 at 5:35 AM David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everybody,
>
> After receiving a private question, I'd like to clarify something: I’m
> hoping that anybody interested in the Swift Open Source project,
> contributor or not, WWDC ticket holder or not, should feel free to come!
> This is definitely not something I meant to be restricted in any way. My
> original wording wasn’t entirely clear.
>
> So, if you like Swift, if you have an interest in discussing about the
> Open Source project, please feel welcome to subscribe!
>
> David.
>
> On 07 Jun 2016, at 08:46, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Of course, I wouldn’t want to exclude anybody by default! In that case,
> I’m proposing dinner somewhere.
>
> I’ve setup a Google Forms to help organise it:
>
> http://goo.gl/forms/Oq6dK9fPNSCAVfL72
>
> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev <
> swift-corelibs-...@swift.org> wrote:
>
> +1 to both points :)
> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev <
> swift-corelibs-...@swift.org> wrote:
>
>> I would love to join as well!!
>>
>> I'd like to propose perhaps to plan something alternative to beers to
>> keep it inclusive to members who may not be 21 or like to drink alcohol :)
>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> +1  I'd love to put some faces to some names  :)  sounds fun!
>>>
>>> Shane
>>>
>>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users <
>>> swift-us...@swift.org> wrote:
>>>
>>> I'd be interested in catching up. Was curious if there was going to be a
>>> meet up, either formal or informal. Sounds good.
>>>
>>> -Rod
>>>
>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> I imagine that during WWDC a non-negligible proportion of the Swift Open
>>> Source contributors will be in or around San-Francisco. I’d very much like
>>> to profit from that opportunity to meet-up, get to know each other, talk
>>> Swift over some beers! Is anybody interested? If yes, any ideas for
>>> location? I can setup a Doodle once I see enough interest.
>>>
>>> Looking forward to meet you!
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> ___
>>>
>>>
>>> swift-users mailing list
>>> swift-us...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> --
>> Javier Soto
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] WWDC Meetup

[Javier Soto via swift-evolution]

I would love to join as well!!

I'd like to propose perhaps to plan something alternative to beers to keep
it inclusive to members who may not be 21 or like to drink alcohol :)
On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution <
swift-evolution@swift.org> wrote:

> +1  I'd love to put some faces to some names  :)  sounds fun!
>
> Shane
>
> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users <
> swift-us...@swift.org> wrote:
>
> I'd be interested in catching up. Was curious if there was going to be a
> meet up, either formal or informal. Sounds good.
>
> -Rod
>
> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I imagine that during WWDC a non-negligible proportion of the Swift Open
> Source contributors will be in or around San-Francisco. I’d very much like
> to profit from that opportunity to meet-up, get to know each other, talk
> Swift over some beers! Is anybody interested? If yes, any ideas for
> location? I can setup a Doodle once I see enough interest.
>
> Looking forward to meet you!
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
>
>
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Javier Soto via swift-evolution]

I have never taken advantage of this. In fact, I didn't know this was
possible until just now :) and I would've definitely found it confusing to
see a function call with "out of order" parameters.
On Thu, Mar 31, 2016 at 7:58 AM Developer via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> ~Robert Widmann
>
> 2016/03/31 10:26、Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
>
> I have never taken advantage of this, personally. Given that there isn’t
> anything that this feature enables that can’t be done if it’s removed—aside
> from reordering arguments—I’d be in favor of removing it for simplicity’s
> sake.
>
> Jeff Kelley
>
> slauncha...@gmail.com | @SlaunchaMan  |
> jeffkelley.org
>
> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Many people are surprised when they find out defaulted parameters can be
> reordered, unlike required arguments. This special case adds complexity to
> the language, and runs against our general trend of treating argument
> labels as a significant part of an API's name, and preferring a single way
> of writing API calls. I think it's worth revisiting this design choice—is
> the special case worth the complexity? How many people take advantage of
> default argument reordering?
>
> -Joe
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[Javier Soto via swift-evolution]

I would add to what Joe mentioned above the fact that the concept of
"selector" may not mean a whole lot to developers who are first introduced
to Swift without any prior Obj-C or Cocoa experience. Thinking of them as
functions I believe avoids introducing complexity in the form of additional
concepts that one must understand and differentiate ("what's a selector and
why/how is it different from a function value?")
On Sun, Dec 27, 2015 at 10:07 AM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Dec 26, 2015, at 11:48 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi all,
> >
> > Currently, producing an Objective-C selector in Swift is an error-prone
> operation. One effectively just writes a string literal and uses it in a
> context where an ObjectiveC.Selector is expected:
> >
> >   control.sendAction(“doSomething:”, to: target, forEvent: event)
> >
> > There are many points of failure here:
> >
> > 1) The compiler doesn’t syntax-check at all to make sure it’s a valid
> spelling for a selector
> > 2) The compiler doesn’t look for existing methods with this selector
> anywhere
> > 3) The mapping from a Swift method name to an Objective-C selector isn’t
> always immediately obvious (especially for initializers), and will be
> getting significantly more complicated with the renaming work for Swift 3 (
> https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md
> ).
> >
> > I suggest that we add an expression ‘objc_selector(method-reference)`
> that produces the Objective-C selector for the named method, and produces
> an error if the method does not have an Objective-C entry point. For
> example:
> >
> >   control.sendAction(objc_selector(MyApplication.doSomething), to:
> target, forEvent: event)
> >
> > “doSomething” is a method of MyApplication, which might even have a
> completely-unrelated name in Objective-C:
> >
> >   extension MyApplication {
> >   @objc(jumpUpAndDown:)
> >   func doSomething(sender: AnyObject?) { … }
> >   }
> >
> > By naming the Swift method and having objc_selector do the work to form
> the Objective-C selector, we free the programming from having to do the
> naming translation manually and get static checking that the method exists
> and is exposed to Objective-C.
> >
> > This proposal composes with my “Generalized Naming for Any Function”
> proposal, which lets us name methods fully, including getters/setters:
> >
> >   let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`)
> // produces the Selector “insertSubview:atIndex:"
> >   let sel2: Selector = objc_selector(UIView.`frame.get`) // produces
> the Selector “frame"
> >
> > I don’t like the `objc_selector` syntax at all, but otherwise I think
> this functionality is straightforward.
>
> Selectors can be seen as "just" a kind of function value. Do we need a new
> syntax form at all? We ought to be able to turn an unbound function
> reference like UIView.insertSubview into a selector reference in Selector
> type context, or maybe a typed @convention(selector) function as discussed
> in another thread, without any explicit get-a-selector operation.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] allow protocol extensions to contain inheritance clauses

[Javier Soto via swift-evolution]

I believe what you're looking for is here under "complete generics"
https://github.com/apple/swift-evolution/blob/master/README.md
On Fri, Dec 25, 2015 at 8:23 AM Sash Zats  wrote:

> That would be great! Is there a comprehensive list of features that made
> it under the cut?
> All I'm finding points to swift-evolution repo and API design guidelines.
>
> On Fri, Dec 25, 2015 at 8:09 AM Javier Soto  wrote:
>
>> If I understood your proposal correctly, this is already planned to be
>> possible in Swift 3 :)
>> On Thu, Dec 24, 2015 at 9:05 PM Sash Zats via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hello,
>>> I ran into several cases when it would be desirable to add an
>>> inheritance clause B in the protocol extension A. Briefly, my proposal is
>>> that compiler should not produce an error once `extension A: B` implements
>>> all the functions of the protocol B, making it formally confirming to it.
>>> Sadly, currently, there is no elegant way to mark the conformance formally.
>>> A more detailed draft can be found here
>>> https://gist.github.com/zats/52476a83627f5e4c0a85
>>> I would really appreciate your feedback and thoughts on this.
>>> Thank you.
>>>
>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> --
>> Javier Soto
>
> --
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Javier Soto via swift-evolution]

and you get to test betas of future iOS releases anyway, so if something
breaks, you'll catch it and release a fix.

That assumes that all apps get updated when new OS releases come out, and
that's not true. Many apps stop being maintained, but they may have many
users, and Apple does whatever they can to make sure apps don't break when
users update iOS. The reality is that Apple spends a lot of time working
around hacks implemented in apps like swizzling, etc.

I'm really worried about the world where monkey-patching iOS internals is
no longer possible

I'm excited about that world, because Apple won't have to waste time
worrying about ugly hacks, and they can focus on fixing bugs instead.

In any case, this proposal is about final by default. Final is already part
of the language, and I'm sure Apple wouldn't hesitate to use it extensively
when/if they write frameworks in Swift, so I don't think this proposal
would change that.
On Sun, Dec 20, 2015 at 1:17 PM Andrey Tarantsov 
wrote:

> This is another proposal that's right on principle, but breaks down in
> real-world scenarios.
>
> To play devils advocate, take for example UINavigationController in UIKit
> on iOS.
>
>
> This.
>
> Real iOS apps subclass and override things that were never supposed to be
> overridden, swizzle iOS internals and do a lot of other nasty stuff,
> because sometimes that's the only way to get the effect you want, and you
> get to test betas of future iOS releases anyway, so if something breaks,
> you'll catch it and release a fix.
>
> I'm really worried about the world where monkey-patching iOS internals is
> no longer possible. Thankfully, a Swift-based UIKit isn't anywhere on the
> horizon.
>
> ON THE OTHER HAND, I do agree with this proposal for our own code. I've
> always used
>
> // override point
>
>
> to mark methods designed to be overridden, and a keyword to document this
> formally would be appreciated.
>
> A.
>
> --
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution