Re: [swift-evolution] #pragma

[Jean-Daniel Dupas via swift-evolution]

> Le 5 sept. 2016 à 00:53, isidoro carlo ghezzi via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> I think the "old style" `#pragma` is necessary in Swift.
> Exactly in the same way it is available in C/C++ or Objective-C/C++, or in 
> something else portable way.
> 
> Because `#pragma` is not handled in Swift, in Xcode they overloaded the 
> semantic of comments, giving to the comment `// MARK:` the semantic of 
> `#pragma mark`
> 
> But my point of view is that, I would like that what it is written in a 
> source comment (what it is written after a // or between /* */ ) should be 
> fully ignore by compiler or IDE.
> 
> I understand that maybe a compiler shouldn't lose time handling `#pragma 
> options`, but giving semantics to source comment, I think it can be dangerous 
> and misunderstood.
> 
> The implementation in Swift compiler should be simple, ignoring any line 
> beginning with `#pragma` (ok I know It is not simple)
> The IDE will handle the `#pragma`
> 
> That's why they invented `#pragma`in C/C++ Objective-C/C++ right?

I don’t think it is a reason pragma exists. except for #pragma mark, I’m not 
sure the compiler ignore any pragma. They are used to control the compiler 
behaviors (controlling warning, specifying linker dependencies, enabled 
specific feature like OpenMP, etc…) and not at all to interact with the IDE. I 
would even says that pragma mark is an abuse of the #pragma construct as it is 
ignored by the compiler and used by the IDE only.

I’m strongly again introducing #pragma without very very good reason into 
swift. Asking the IDE to parse comment to extract metadata is not worst abusing 
pragma to do the same, and at least it is forward and backward compatible with 
any other tools.

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

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Jean-Daniel Dupas via swift-evolution]

> Le 3 sept. 2016 à 06:43, Georgios Moschovitis via swift-evolution 
>  a écrit :
> 
>> Can it be corrected in Swift 4 (breaking changes etc…)?
> 
> Good question.
> Maybe the core team should accept additional source-breaking changes in 3.x 
> releases?


I think the framework API mapping itself is not part of the language and is 
handle by Apple directly (at least for Apple specifics frameworks). I don’t 
know if such changes are subject to the same policy.




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

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

[Jean-Daniel Dupas via swift-evolution]

> Le 15 août 2016 à 10:01, Justin Jia via swift-evolution 
>  a écrit :
> 
> 
>> On Aug 15, 2016, at 3:53 PM, Charlie Monroe > > wrote:
>> 
>>> 
>>> On Aug 15, 2016, at 9:46 AM, Justin Jia via swift-evolution 
>>> > wrote:
>>> 
>>> I think the `?` will make the return an optional. So your example should 
>>> add another ? at the end.
>>> 
>>> ```
>>> print(foo(bar(42)?, baz(42)?)?)
>> 
>> This reads terribly, IMHO.
>> 
> 
> I agree that this reads terribly. But this is only an edge case. I would 
> prefer `let output = foo(bar(42)?, baz(42)?); print(output?)`. However, I 
> want to argue that for most cases “?” reads better than “if let”.
> 
>>> ```
>>> 
>>> The above example should be equivalent to:
>>> 
>>> ```
>>> let x = bar(42) // X is optional
>>> let y = baz(42) // Y is optional
>>> 
>>> let z = foo(x?, y?) // Z should be optional now
>>> print(z?)
>>> ```
>>> 
>>> which should be equivalent to;
>>> 
>>> ```
>>> let x = bar(42)
>>> let y = baz(42)
>>> 
>>> if let x = x, let y = y {
>>> z = foo(x, y)
>>> }
>> 
>> What if baz doesn't return optional?
>> 
> 
> If baz doesn’t return optional, then we don’t even need this syntax:
> 
> We can just write: `z(bar(42)?, baz(42)` and treat baz(42) like normal.
> 
> Which should be equivalent to:
> 
> ```
> ```
> let x = bar(42)
> let y = baz(42)
> 
> if let x = x {
> z = foo(x, y)
> }
> ```
> 

It is not consistent which what I expect when calling foo?.bar(baz(42))

In that case, if foo is nil, bad is never evaluated.


>> if let x = bar(42) {
>>  let y = baz(42)
>>  z = foo(x, y)
>> }
>> 
>> or 
>> 
>> let y = baz(42)
>> if let x = bar(42) {
>>  z = foo(x, y)
>> }
>> 
>> 
>> If both are evaluated, this is really inconsistent with
>> 
>> if let x = bar(42), y = baz(42) { ... }
>> 
>> which will short-circuit and baz will not be evaluated if x is evaluated as 
>> nil.
>> 
>>> 
>>> if let z = z {
>>> print(z)
>>> }
>>> ```
>>> 
>>> We don’t need to worry about “short-circuit” now because it should be 
>>> equivalent to the above syntax.
>>> 
>>> > It has been mentioned before (more than once, perhaps, but not in its own 
>>> > thread I don't think, so good luck finding it). IIRC, one of the problems 
>>> > is that it's unclear what happens if your function takes multiple 
>>> > arguments. Does evaluation proceed from left to right? does it 
>>> > short-circuit? Put concretely:
>>> > 
>>> > ```
>>> > func bar(_ x: Int) ->Int? { /* side effects */ }
>>> > func baz(_ y: Int) ->Int? { /* side effects */ }
>>> > func foo(_ z: Int, _ a: Int) ->Int { /* ... */ }
>>> > 
>>> > print(foo(bar(42)?, baz(42)?))
>>> > ```
>>> > 
>>> > Does baz(42) get evaluated if bar returns nil? Does bar(42) get evaluated 
>>> > if baz returns nil?
>>> > 
>>> > 
>>> > On Mon, Aug 15, 2016 at 2:02 AM, Justin Jia via 
>>> > swift-evolution>> > (mailto:swift-evolution@swift.org 
>>> > )>wrote:
>>> > > Hi!
>>> > > 
>>> > > I don’t know if this has came up before. I tried to search though the 
>>> > > mailing list but didn’t find any related threads.
>>> > > 
>>> > > This is purely a syntactic thing (which I know it’s the lowest priority 
>>> > > for Swift 4), but I think it’s an important one.
>>> > > 
>>> > > Let’s say we have a struct with a function:
>>> > > 
>>> > > ```
>>> > > struct Foo {
>>> > > func bar(x: Int)
>>> > > }
>>> > > ```
>>> > > 
>>> > > We can use optionals:
>>> > > 
>>> > > ```
>>> > > let foo: Foo? = nil
>>> > > let x = 1
>>> > > foo!.bar(x: x) // Able to compile, but will cause runtime error
>>> > > foo?.bar(x: x) // Able to compile, and won't cause runtime error
>>> > > ```
>>> > > 
>>> > > However:
>>> > > 
>>> > > ```
>>> > > let foo = Foo()
>>> > > let x: Int? = nil
>>> > > foo.bar(x: x!) // Able to compile, but will cause runtime error
>>> > > foo.bar(x: x?) // Won't compile
>>> > > ```
>>> > > 
>>> > > I propose that we should allow `foo.bar(x: x?)`, which should be 
>>> > > equivalent to:
>>> > > 
>>> > > ```
>>> > > if let x = x {
>>> > > foo.bar(x: x)
>>> > > }
>>> > > ```
>>> > > 
>>> > > What do you think?
>>> > > 
>>> > > Thanks,
>>> > > Justin
>>> > > 
>>> > > ___
>>> > > swift-evolution mailing list
>>> > > swift-evolution@swift.org 
>>> > > (mailto: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 
>>> 

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

[Jean-Daniel Dupas via swift-evolution]

> Le 14 août 2016 à 20:43, Karl via swift-evolution  
> a écrit :
> 
> 
>> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution 
>>  wrote:
>> 
>> Hi folks,
>> 
>> I see from building the latest Swift-3.0 branch that I’m a little behind the 
>> times and this proposal has been accepted :(
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>> 
>> Is there no way we can revisit this decision? 60 emails on a mail group not 
>> read by the whole community
>> doesn’t quite seem enough validation for such a significant change to me. Of 
>> those that expressed an
>> opinion on the thread many were against sealing classes outside the module. 
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html
>> 
>> I personally feel it's a huge mistake for the following reasons:
>> 
>> 1) it “breaks open source” reducing the reusability of third party software 
>> by default.
>> 
>> 2) Contrary to arguments about the likely performance benefits of 
>> de-virtualisation of method dispatch it is
>> likely to make Swift programs launch more slowly due to the dynamic linker 
>> having to slide large numbers
>> of function pointers for most method calls (itself an expensive operation) 
>> whether a call is even made.
>> 
>> On the first point it's an established technique in OOP to be able to 
>> subclass and override to adapt a class
>> for a role perhaps it’s author never considered. Call this “monkey-patching” 
>> if you like but it is a part of being
>> able to use open source libraries without having to make a fork as would be 
>> the case if sealed by default.
>> Are we expecting developers to remember to leave their classes (and 
>> methods?) "open”? If they do feel
>> that others shouldn’t subclass or override there was always “final". 
>> Distinctions about whether this is possible
>> inside or outside a module seem a mute point to me.
>> 
>> The second point is more of an engineering one. “Virtual” dispatch on Swift 
>> is not a significant overhead
>> compared to fully dynamic dispatch on Objective-C which even then was seldom 
>> a problem. There is a
>> cost however to de-virtualisation and resolving to a direct call to a method 
>> address in that the dynamic
>> linker has to resolve and slide the pointer on load. This type of concern is 
>> a bad argument to use in 
>> designing a language anyway even if it is called Swift.
>> 
>> Well, I know the boat has left on this one and I’ll likely have to live with 
>> it but this is the proposal I
>> most disagree with on evolution this far. Programmers have morals and just 
>> because you shouldn’t
>> do something doesn’t mean the language needs to turn that into can’t by 
>> default when the need arises.
>> If this change does go ahead please try to get it into the next Xcode beta 
>> as it is a very incompatible one.
>> 
>> Cheers,
>> 
>> John
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> It we are happy with non-open != final, I would be in favour of some kind of 
> monkey-patching import attribute, similar to @testable, which allows you to 
> subclass non-open classes at your own risk.
> 

The non subclassable across module boundary is not just a compiler enforced 
limitation. Once you compile a module with classes that are ‘final’ in the 
module, the compiler may devirtualize all call sites in the module, or even 
inlining some calls, making subclassing unpredictable and pointless.


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

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

[Jean-Daniel Dupas via swift-evolution]

> Le 14 août 2016 à 11:17, John Holdsworth via swift-evolution 
>  a écrit :
> 
> Hi folks,
> 
> I see from building the latest Swift-3.0 branch that I’m a little behind the 
> times and this proposal has been accepted :(
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Is there no way we can revisit this decision? 60 emails on a mail group not 
> read by the whole community
> doesn’t quite seem enough validation for such a significant change to me.

60 emails ?  You’re joking. It is more 600 emails than 60 that was send about 
that proposal, and I’m pretty sure nobody want to see that discussion start 
again.


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

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jean-Daniel Dupas via swift-evolution]

> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution 
>  a écrit :
> 
> With NSError, you must check the domain before trying to interpret the code, 
> or else your code is buggy and will behave incorrectly when receiving an 
> unexpected error. 

You must check before interpreting the code, but you don’t have to interpret 
the code to do something useful with an NSError. 

I think what Jon is looking for is ‘LocalizedError’ and ‘CustomNSError’.
Is there any guarantee that casting an NSError into a CustomNSError or 
LocalizedError will always succeed ?

> With SE-0112, instead of checking the domain, you check if the Error can be 
> casted to the particular error type that represents the domain. There is a 
> one-to-one correspondence between domains and the new error types. For 
> example, NSCocoaErrorDomain is represented by CocoaError, NSURLErrorDomain is 
> URLError, etc.
> 
> So previously you might have code that looks like
> 
> func handleError(error: NSError) {
> switch error.domain {
> case NSCocoaErrorDomain where error.code == NSFileNoSuchFileError:
> let path = error.userInfo[NSFilePathErrorKey] as? String
> // handle error for path
> case NSURLErrorDomain where error.code == NSURLErrorTimedOut:
> let url = error.userInfo[NSURLErrorKey] as? NSURL
> // handle error for url
> default:
> // generic handling of other errors
> }
> }
> 
> And now you'd write that like
> 
> func handleError(error: Error) {
> switch error {
> case let error as CocoaError where error.code == .fileNoSuchFileError:
> let path = error.filePath
> // handle error for path
> case let error as URLError where error.code == .timedOut:
> let url = error.failingURL
> // handle error for url
> default:
> // generic handling of other errors
> }
> }
> 
> It's the same basic structure, except now you get strong typing, you can't 
> possibly forget to check the domain (which is a surprisingly common bug I see 
> in a lot of code), and you get convenient accessors for the values stored in 
> the user info.
> 
> And if you don't actually care about any of the user info properties, then 
> the new version is much simpler than the old:
> 
> func handleError(error: Error) {
> switch error {
> case CocoaError.fileNoSuchFileError:
> // handle error
> case URLError.timedOut:
> // handle error
> default:
> // generic handling of other errors
> }
> }
> 
> It's similar to checking the code without the domain in the old style, except 
> now it checks the domain automatically, so you still can't accidentally 
> interpret an error's code in the wrong domain.
> 
> -Kevin Ballard
> 
> On Thu, Aug 4, 2016, at 11:00 AM, Jon Shier via swift-evolution wrote:
>> Doug:
>> Thanks for indulging me so far, I think I’ve almost got it. Prior to this, 
>> using NSError, I could just look at the relevant properties of the error if 
>> I needed to see what type it was. Network errors had different codes from 
>> CloudKit errors, POSIX errors were underlying FileManager errors. A bit 
>> complex due to the undocumented nature of so many of these errors, but I 
>> could ignore any aspect of the error I didn’t care about. Now, however, it 
>> seems I must always care about what types of errors come out of various 
>> methods, as I’ll need to cast to the appropriate types to get useful 
>> information. For example, how would you handle the CloudKit errors I 
>> mentioned before? It seems to me like I would need to, at the point where I 
>> need to extract useful information, do a switch on various casts. First, try 
>> casting to CKError, then to CocoaError (?), and then likely produce a 
>> fatalError if there’s an unexpected type. Or is Error guaranteed to always 
>> cast to something useful? I’ve read the proposal a few times now and it 
>> looks like a lot of casting is going to be required, I’m mostly curious 
>> about the recommended patterns, especially for asynchronous calls that don’t 
>> go through throw/catch. 
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Aug 2, 2016, at 5:36 PM, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Aug 2, 2016, at 2:19 PM, Jon Shier > wrote:
 
 Thanks Doug. I missed the rename, as earlier points still referred to 
 ErrorProtocol. In regards to the CloudKit errors, I appreciate the 
 strongly typed CKError, but why not have the methods return that type 
 directly?
>>> 
>>> Generally speaking, Cocoa only uses NSError—not specific subclasses or 
>>> NSError or other error types—because errors can occur at many different 
>>> places in the stack and be propagated up. A CloudKit operation could fail 
>>> because of some problem detected in a different error domain—say, the 
>>> general Cocoa error domain or URLError domain—and that 

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 16 juil. 2016 à 18:05, Jose Cheyo Jimenez via swift-evolution 
>  a écrit :
> 
>>  * What is your evaluation of the proposal?
> 
> +1 as before but I do have concerns
> 
>   * Why do open classes need to have also have open superclasses? 
>   * I don’t think sealed methods/properties as default is the right 
> default. 
>   * If the default was open for methods/properties, then do we really 
> need the sealed keyword? Could’t we just use final for that?
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Requiring super classes to also be Open seems wrong. 

> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 
> 
> We already have to mark all public methods/properties as public, if I need 
> something not the be overridable then I can just use final. This would work 
> the same across all classes. 
> 
> If I was a framework author that initially just had a library that was sealed 
> but then somebody asked me to make it open; All I would want to do is add 
> open to the class only, I would not want to spend the time to go back an add 
> open to all public methods/properties specially if I am already using final. 
> I think having method/properties open by default is the best compromised. I 
> can see framework authors switching a class to be open and expecting that 
> everything in the class in open and if they don’t open any methods, then what 
> possible use is a subclass than an extension could not provide?

Extensions do not support stored properties (yet?). Subclasses do. That said, I 
agree that having an open class without any open member does not has much 
benefit, but I’m sure we can find a valid use case for such class.

> I think that is an overreach to make the framework author have to add open to 
> every public method in addition to having to open every super class. As a 
> framework author if I think my clients could use subclassing, all I want to 
> do is flip a switch on the classes that I want to make subclass able  and 
> then just push a new version. As a framework user I want to be able to tell 
> my framework author “can you just add open to classes abs and deca etc.” I 
> think it is more likely that I will get my request if it is easy vs it the 
> framework author needs to touch every class in the hierarchy. 
> 
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> n/a
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> reviewed previously and followed the update. 
> 
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution 
>  a écrit :
> 
> 2016/07/15 16:37、Riley Testut via swift-evolution  > のメッセージ:
> 
>> FWIW, I'm still against this proposal, but since it will be accepted 
>> regardless, here are my thoughts:
>> 
>> • Open keyword is significantly better. 
>> • Members should be *open* by default, and final should be opt-in. If you're 
>> opening up a class for subclassing, my gut says you should allow the client 
>> to do as they wish.
> If you have a class that was not open yet, just making it open wouldn't 
> expose any members: it would then just be subclassable.
> 
> If the act of making the class open doesn't implicitly make overriding 
> possible, well all you can do then is add methods, and that can be done with 
> extensions anyways, so it's not as useful and makes the public open class {} 
> pattern just by itself not so useful imho... 
> 
> Also, the keyword 'open' itself may imply 'hey I'm open, please do what you 
> want with my public members', whereas 'subclassable' is more specific in 
> intention...  (but that's just me, so n=1 and all that)
> 
> TLDR; +1 to the above: simpler is better and defaulting to overridable for 
> public members on an open class is simpler... invariants can be protected by 
> the 'final' keyword.
> 
> If we were to default to non-overridable, a more consistent 'open' on the 
> method is preferred over overridable for me... open class, open method... 
> much better imho...

Do we really need an open keyword ?

As already said, if open does nothing more than allowing the class to be 
subclassed, why not simply make the class subclassable if it contains at least 
one overridable member ?

In case we require an open keyword, what would happen if someone mark a member 
overridable, but does not make the class open ? Will the compiler emit an 
error, or make the class implicitly « open » ? 

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 12 juil. 2016 à 21:29, Jean-Denis Muys via swift-evolution 
>  a écrit :
> 
> * What is your evaluation of the proposal?
> 
> I am strongly opposed to that proposal. I am mostly a lurker on this list, 
> the volume of which I cannot cope with. However, I feel this proposal is 
> important enough that I decided to invest more time than usual.
> So I have read carefully the arguments presented here.
> And I am still opposed to the proposal.
> I believe no programmer, least of which myself, can be trusted with the 
> decision to reliably decide ahead of time that this or that class cannot or 
> will not be subclassed.

If you can’t trust a developer, how could you use its library ? Using 
third-party code involve some kind of trusting, as you would have to trust the 
developer to write reliable and efficient code, which is IMHO, far more 
important than knowing if the developer carefully choose what can be subclasses 
or not.

And when you encounter a library where the dev choose to allow subclassing, you 
will have far more trust than the code was design to be subclassed.

Some design patterns work better with subclassing than with protocol or 
delegation. So I’m confident than library developers will ‘open’ there classes 
if needed.

> So strong -1 for me.
>  
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> 
> I don't think the problem is a problem at all.
>  
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Not in my mind. Swift aims for safety, but not at the price of inflexibility
> 
> 
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> I would compare it for example to the decision for the C++ developer to mark 
> methods virtual or not, with the usual recommendation to mark everything 
> virtual, especially the destructor
> 
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> I read it and ready carefully the debate on this list.
>  
> 
> On Tue, Jul 12, 2016 at 5:36 PM, Jon Akhtar via swift-evolution 
> > wrote:
> I completely agree, the programmer should have as much power as we can
> give them, even if it means allowing them to shoot themselves in the foot,
> because at the end of the day Swift isn¹t an academic exercise, it is a
> real world programming language, so it should be optimized for solving
> real world problems not having some kind of technical, philosophical, and
> stylistic perfection when those come at the cost of the former.
> 
> So -1
> 
> -Jon
> 
> On 7/11/16, 16:00, "swift-evolution-boun...@swift.org 
>  on behalf of
> Jonathan Hull via swift-evolution"   on
> behalf of swift-evolution@swift.org > wrote:
> 
> >
> >> On Jul 10, 2016, at 7:48 PM, Rod Brown  >> > wrote:
> >>
> >>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull  >>> > wrote:
> >>>
> >>> It is pre-breaking in that it is the exact same code that doesn¹t work
> >>>in both cases (only in the pre-breaking case, a bunch of other code
> >>>also doesn¹t work).  I know it feels different because it ³was never
> >>>possible² vs our change being the cause, but it is one of those things
> >>>like me giving you $5 or giving you $10 and later taking back $5.  As
> >>>humans we are loss averse so we devise strategies to hide the loss from
> >>>ourselves.
> >>
> >> I completely disagree with this.
> >>
> >> Not providing someone something due to risk of breakage is not the same
> >>thing as ³giving it and taking it away². We don¹t build bridges out of
> >>spare parts and tell people ³We build it but we expect it to break at
> >>some stage, so use with caution.² You either build it correctly, or you
> >>don¹t let people cross the bridge. At All.
> >>
> >> This isn¹t about ³loss averse². This is about risk management.
> >>
> >> Where does the line lie on risk? That¹s ultimately something the core
> >>team will have to decide.
> >
> >My point is that you are completely ignoring an entire class of risk that
> >has a real-world $$$ cost.  Every time I have to use a framework under
> >this proposal, I am now completely at the mercy of the author.  In the
> >case of open source frameworks I can at least make a fork, but for closed
> >source frameworks (often from large companies where us using their
> >framework has been negotiated by the bosses) you have now just added
> >weeks to my development cycle while I wait for
> >big-company-who-doesn¹t-really-care-that-much to update their stuff.
> >(sure I can work on other things during that time, but delaying a 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 11 juil. 2016 à 17:43, Jordan Rose  a écrit :
> 
> 
>> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas  wrote:
>> 
>> Just a though, but why sealed classes have to be completely unsubclassable ?
>> 
>> Wouldn't it be possible to allow the user to subclass sealed class, but deny 
>> overriding of any public member.
>> 
>> I see a use case where a user want to extends an existing model by adding 
>> new properties and new methods to an object but can’t use composition 
>> because doing that will prevent to pass that object to the framework that 
>> expect the base object.
>> 
>> That would let user override existing class to extends them, but should not 
>> cause any side effect in the way the class should behave, and so would not 
>> affects preconditions and postconditions, and should not prevent 
>> optimization in whole module compilation, as the methods of the base class 
>> are considered final outside of the module.
>> 
>> Of course, it will introduce some fragility in the library, as adding new 
>> methods may conflict with user subclass methods, but no more than what would 
>> append if the user write extension to add new methods to the model.
> 
> DaveA and I actually talked about this, and IIRC we decided it was completely 
> safe semantically, and only left a few optimization opportunities on the 
> table (things like knowing what a deinitializer might or might not do). 
> However, we felt it was a more complicated model that still ended up with the 
> “de facto sealed” case of all initializers being non-public, and so it wasn’t 
> worth stopping at that point in the design space.
> 
> (It was a while ago, so I might have forgotten something else relevant.)
> 
> Jordan
> 

OK,

Thanks for the explanation and the long argumentation about why sealed by 
default make sens. You made me change my stance about the proposal. I just hope 
the seal keyword will be properly explained and will not make subclassing a 
second class citizen by discouraging developer to support it.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 11 juil. 2016 à 09:39, Tino Heth via swift-evolution 
>  a écrit :
> 
> 
>> With the existence of Swift on the server, dynamically linked, independently 
>> distributed frameworks will not be an Apple-only issue - this extends beyond 
>> Apple's OS X-based platforms towards how dynamic frameworks link against 
>> each other as if they are to be distributed separately.
>> 
>> It is short sighted to suggest that all Swift deployments will be under 
>> Apple's control.
> I'm really looking forward for server-side Swift — I'm planning for years to 
> extend my portfolio in that direction, and Swift could really push that 
> diversification.

Server side swift is already alive:  https://developer.ibm.com/swift/

> But I had a concrete reason for interest in writing my own backend-code:
> Server-side was imho broken on large scale, and it still isn't fixed yet… I 
> can run circles around those poor Java-developers who have to fight crusted 
> structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).*
> It seems to me I'm not alone with my opinion, because there are already 
> alternatives on the rise:
> Look at Docker — it's a huge success, because it not only takes application 
> and libraries to build a robust unit; it even includes a whole OS!
> 
> On iOS, it already hurts when you have a bunch of Swift-Apps which all have 
> the stdlib bundled — but on the server, this doesn't matter, and I'm 
> convinced it would be a bad move to propagate shared frameworks.
> 
> - Tino
> 
> * of course, there are agile alternatives — but in my environment, most of 
> the big players wouldn't even consider something like Rails
> 
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

Just a though, but why sealed classes have to be completely unsubclassable ?

Wouldn't it be possible to allow the user to subclass sealed class, but deny 
overriding of any public member.

I see a use case where a user want to extends an existing model by adding new 
properties and new methods to an object but can’t use composition because doing 
that will prevent to pass that object to the framework that expect the base 
object.

That would let user override existing class to extends them, but should not 
cause any side effect in the way the class should behave, and so would not 
affects preconditions and postconditions, and should not prevent optimization 
in whole module compilation, as the methods of the base class are considered 
final outside of the module.

Of course, it will introduce some fragility in the library, as adding new 
methods may conflict with user subclass methods, but no more than what would 
append if the user write extension to add new methods to the model.

> Le 11 juil. 2016 à 05:38, Jordan Rose via swift-evolution 
>  a écrit :
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>  
> 
>  ]
> 
> (This is my second response to this proposal. The previous message shared a 
> use case where public-but-non-subclassable made things work out much better 
> with required initializers. This one has a bit more ideology in it.)
> 
> As many people have said already, this proposal is quite beneficial to 
> library designers attempting to reason about their code, not just now but in 
> the future as well. The model laid out in the Library Evolution document 
>  (often referred to as 
> “resilience”) supports Swift libraries that want to preserve a stable binary 
> and source interface.
> 
> In the Swift 2 model (and what’s currently described in that document), a 
> public class must be final or non-final at the time it is published. It’s 
> clearly not safe to add ‘final' in a later version of the library, because a 
> client might already have a subclass; it’s also not safe to remove ‘final’ 
> because existing clients may have been compiled assuming there are no 
> subclasses.
> 
> (Of course, we can remove this optimization, and make ‘final’ a semantic 
> contract only. I’m deliberately avoiding most discussion of performance, but 
> in this parenthetical I’ll note that Swift makes it possible to write code 
> that is slower than Objective-C. This is considered acceptable because the 
> compiler can often optimize it for a particular call site. For those who want 
> more information about the current implementation of some of Swift’s 
> features, I suggest watching the “Understanding Swift Performance 
> ” talk from this 
> year’s WWDC.)
> 
> With this proposal, a public class can be non-publicly-subclassable or 
> publicly-subclassable. Once a class is publicly-subclassable (“open”), you 
> can’t go back, of course. But a class that’s not initially open could become 
> open in a future release of the library. All existing clients would already 
> be equipped to deal with this, because there might be subclasses inside the 
> library. On the other hand, the class can also be marked ‘final’, if the 
> library author later realizes there will never be any subclasses and that 
> both client authors and the compiler should know this.
> 
> One point that’s not covered in this proposal is whether making a class 
> ‘open’ applies retroactively, i.e. if MagicLib 1.2 is the first version that 
> makes the Magician class ‘open’, can clients deploy back to MagicLib 1.0 and 
> expect their subclasses to work? My inclination is to say no; if it’s 
> possible for a non-open method to be overridden in the future, a library 
> author has to write their library as if it will be overridden now, and 
> there’s no point in making it non-open in the first place. That would make 
> ‘open’ a “versioned attribute 
> ”
>  in the terminology of Library Evolution, whatever the syntax ends up being.
> 
> ---
> 
> Okay, so why is this important?
> 
> It all comes down to reasoning about your program’s behavior. When you use a 
> class, you’re relying on the documented behavior of that class. More 
> concretely, the methods on the class have preconditions 
> (“performSegue(withIdentifier:sender:) should not be called on a view 
> controller that didn’t come from a storyboard”) and postconditions (“after 
> calling loadViewIfNeeded(), the view controller’s view will be loaded”). When 
> you call a method, you’re responsible for satisfying its preconditions so it 
> can deliver on the postconditions.
> 
> I used UIViewController 

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

Interesting example but it only explain that a sealed keyword is needed (which 
I agree), and not why sealed should be the default (which I disagree).

> Le 10 juil. 2016 à 21:18, Leonardo Pessoa  a écrit :
> 
> Should I assume then you want so much this proposal to be dropped you didn't 
> even mind to look for the example so you wouldn't have to admit this proposal 
> is needed? Fine, here is the whole of that example.
> 
> I'm currently working on an app which will have object representations of 
> Files and Folders (both come from a common class called Entry). You as a 
> developer for this system will be entitled to extend from File and Entry 
> freely but you can only work with Folders and its subclasses (specialised 
> folders) but to this system it is important you don't subclass any type of 
> folder. Without this proposal I would have to create workarounds to prevent 
> you from doing that while still allowing me to subclass while playing a lot 
> of finals everywhere. And so far I would have to allow you to subclass Folder 
> itself (at least) but you would complain (and possibly file a bug report to 
> me) because it would not be working properly because your classes would not 
> benefit from the workaround. In this case, if I could subclass internally but 
> prevent you from doing it, you could complain I'm not allowing you to do 
> whatever you want but you wouldn't complain my code doesn't work properly (it 
> does, you just won't know it).
> 
> There may be several more examples but this is one I'm facing right now, so I 
> can assure you it is a true example. IMO libraries are to be written with 
> intention in mind and I don't think it is right to use a library written to 
> compose a PDF file to send an email (even if you're sending the PDF file 
> attached, the right way to do it is by composition not subclassing).
> 
> Additionally, someone mentioned and I went in to check about a recommendation 
> for Java to intentionally document and enable classes to be subclasses 
> explicitly otherwise forbid it at all and that recommendation seems to come 
> from Oracle itself. I believe Oracle would do it to Java if it had great 
> interest in it without consulting anyone's opinion.
> 
> About the addition to the proposal to enable force unsealing, I'm completely 
> opposed as it is just like not having any of this protection at all (why 
> putting a lock on the door to your house if the key is under the mat?)
> 
> Swift doesn't have to follow on the footsteps of any language but what is 
> best for the intention the language was created for. If sealed by default 
> goes in that direction, then we should have it not looking back. The same 
> goes if we decide this is not taking the language in its intended direction. 
> If I'm not wrong at least one member of the core team already mentioned in 
> this thread this is completely aligned with the intention of the language, so 
> I think we should give it a go and stop trying to have/keep control of 
> everything we touch.
> 
> L
> From: Tino Heth via swift-evolution 
> Sent: ‎10/‎07/‎2016 01:55 PM
> To: swift-evolution 
> Cc: Jean-Daniel Dupas 
> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
> benon-subclassable publicly
> 
> Two days ago, I challenged the supporters of this proposal to show a singe 
> persuasive example to illustrate that this proposal could actually improve 
> something.
> I got a single reply — which did not contain an example, but just the claim 
> that there is one…
> Imho that alone should be enough to cancel the whole thing, because even if 
> there are cases which cannot be repelled with the simple advice "just don't 
> subclass", this would only be a basis to start talking about the actual pros 
> and cons.
> 
> So for me, the promised benefits are less likely than the existence of 
> Bigfoot:
> I guess there are at least several hundred people who swore they have seen 
> him, and there are even some blurry photos ;-)
> 
> Of course, it is impossible to come up with an unquestionable argument for 
> the change — and it's also impossible to prove the opposite, because the 
> whole debate makes as much sense as arguing wether raisins are tasteful or 
> terrible; it's nothing but personal preference, and the only thing we can 
> hope for is that the bias of those who will decide this proposal isn't at 
> odds with the needs of the majority.
> 
> If we can agree that it is not about facts, but about opinion, there are 
> still fundamental arguments against SE-0117:
> Those who have issues with subclassing can just resign from it (as users of a 
> library), and they can annotate their classes to dictate their usage (as an 
> author) — but if you think subclassing is still a good tool, you can't do 
> anything with a sealed class.
> Additionally, please note that those who ask for stricter 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution 
>  a écrit :
> 
> 
> Regards
> (From mobile)
> 
> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>>> On Jul 9, 2016, at 8:39 AM, Andre >> > wrote:
>>> 
>>> Personally, Im not against sealed by default, but I think there are cases 
>>> where closed source libraries have certain cases where workarounds are 
>>> necessary, and just sealing by default will prevent those cases. 
>>> 
>>> One could say, "well just use an open source one, or change vendors" but 
>>> its not that easy in The Real World™ where we get certain SDKs shoved down 
>>> our throats by the suits… and while that may be a separate issue to the one 
>>> at hand, its still a problem that won’t resolve itself by simply locking 
>>> down things…
>>> 
>>> In my own case, Ive fought with NSBrowser / NSTreeController in the past 
>>> and the only way to resolve things was to subclass (and no, waiting 1 or 2 
>>> years for a fix is not acceptable if you already have a product in the 
>>> wild).
>>> 
>>> So I am reticent to support this proposal without an escape hatch for those 
>>> cases…
>> 
>> Are you concerned about closed-source vendor frameworks beyond Apple’s?  
>> Some things to consider:
>> 
>> 1. This proposal should not impact any existing libraries - nobody should be 
>> shipping closed-source binary libraries written in Swift yet.
>> 
>> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
>> come.  If / when they are replaced with Swift frameworks the default will 
>> have little (if any) impact on the public API contract.  It is reasonable to 
>> expect that Apple will review the public contracts carefully and add any 
>> annotations necessary to achieve the desired semantics.
>> 
>> 3. In the future, if you depend on any 3rd party closed-source libraries 
>> written in Swift you will be able to ship an update to your app that 
>> contains an updated / fixed version of the library independent of the user 
>> upgrading their OS.
>> 
>> This leaves the scenario of a case where you depend on a 3rd party, 
>> closed-source library written in Swift and where you cannot get (or use) a 
>> fix from the vendor for some reason.  This is a legitimate concern, but IMO 
>> it is not large enough to outweigh all of the advantages of making sealed 
>> the default.  
>> 
>> There is no doubt that adopting sealed by default will place some pressure 
>> on the Swift ecosystem.  As others have noted, this pressure already exists 
>> in the form of value types, protocol-oriented designs, etc - the current 
>> proposal is a relatively modest increase in that pressure.   I believe the 
>> pressure will have a very positive impact over time (the eventual outcome 
>> remains to be seen of course).  
>> 
>> Swift library vendors will need to choose between opening their source, 
>> providing responsive support and bug fixes, explicitly providing the escape 
>> hatch you mention (by designing with open types) or getting a bad reputation 
>> among users.
> 
> There are IMO no advantages to sealing by default. If there were, I cannot 
> imagine how they can have so consistently eluded the designers and 
> maintainers of so many great OOD languages in the last 30 years. Does it mean 
> it is just a matter of time for the core team to take it the c++ 
> standardization committee to make sure C++ gets enhanced the same way?
> 

You can’t compare Swift to C++ here. C++ uses « final » method and static 
dispatch by default, so subclassing does not imply the same fragility than with 
a fully dynamic language.


>> 
>> -Matthew
>> 
>>> 
>>> Andre
>>> 
 2016/07/09 22:11、Shawn Erickson > のメール：
 
 What I don't get in the arguments against this capability is the fact that 
 many constructs in Swift can't be subclassed. Are we going to prevent 
 library developers from presenting those in the public API? Your ability 
 to subclass things when not supported by the library developer is already 
 going to be greatly reduced. Additionally you are going to miss 
 potentially helpful optimization in side the model if the library 
 developer can't prevent extras subclassing.
 
 It seems perfectly reasonable to allow a lot of freedoms for a library 
 developer when designing their code on their side of the library API and 
 not force them to expose unwanted API just because of internal design 
 desires. 
 
 (I have myself have already struggled with having to leak what I consider 
 internal details outside of modules we have developed internally, likely 
 need to get around to outlining the additional issues I see)
 
 In the end if the library isn't good and you don't like the API find one 
 that 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 7 juil. 2016 à 18:23, Leonardo Pessoa via swift-evolution 
> <swift-evolution@swift.org> a écrit :
> 
> Jean, IMO marking every class as subclassable means the creator does
> not care for you to design and develop a great library because s/he is
> not caring for the library at all. I right now have to go through the
> burdensome activity of marking too many classes/methods as final to
> prevent misuse of my libraries and find good design workarounds when I
> need to subclass internally what I don't want you to subclass.
> 
> IMO the usage of a library is to be crafted/planned/designed by their
> developers not their users. Mine is the opinion of a library-maker,
> yours of the user of poorly designed/developed libraries.

If you consider Cocoa and other Apple frameworks as poorly design, then I guess 
you’re right…

Nonetheless, being able to subclass any class allowed me to solve a bunch of 
very bad memory leaks in the new NSCollectionView implementation, and made it 
usable for my project.

Thinking than you will have to work only with perfectly design libraries 
without any bug is utopian.
And thinking you can predict every usages of your library by users is short 
sighted IMHO.

> By pushing
> this proposal, developer of such libraries will have much burden to
> make/keep a poor library or will have to work on better
> design/implementation for it to suit its purpose.
> 
> L
> 
> On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution
> <swift-evolution@swift.org> wrote:
>> * What is your evaluation of the proposal?
>> 
>> Strong -1 too.
>> 
>> I can’t count the number of times it save my hours tone able to override
>> arbitrary classes and methods.
>> 
>> Sometimes to simply add log point to understand how the API work. Other
>> times to workaround bugs in the library. Or even to extends the library in a
>> way that the author did not intent in the first place, but that was
>> perfectly supported anyway.
>> 
>> I already see how libraries author will react to that new default. They will
>> either don’t care and mark all classes as subclassable, or find to
>> burdensome to get subclassability right and prohibit subclassing all
>> classes.
>> 
>> 
>> Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution
>> <swift-evolution@swift.org> a écrit :
>> 
>> * What is your evaluation of the proposal?
>> 
>> A **strong** -1
>> 
>> First, I have often found that you can’t always predict the way which
>> something will need to be extended.  You think you know, but are then
>> surprised by creative uses.  My favorite features of Swift/Cocoa involve
>> retroactive modeling.
>> 
>> Second, I don’t think this proposal will achieve its stated objective of
>> forcing people to think about subclassing more.  It will just add confusing
>> boilerplate.
>> 
>> Things like Swift optionals work well because they make the (often
>> forgotten) choices explicit in the context that they are used.  In the world
>> of Human Factors, we call it a forcing function.  This proposal has the
>> inverse structure, and will be ineffective, because the “forcing” part of it
>> shows up in a different context (i.e. trying to use a framework) than the
>> decision is being made in (writing the framework).  This type of thinking
>> leads to things like Java and the DMV.
>> 
>> As Tino said:
>> 
>> No matter what the defaults are, good libraries are hard to build, so I
>> predict this proposal would not only fail in increasing framework quality,
>> but also will make it much harder for users of those frameworks to work
>> around their flaws, which are just a natural part of every software.
>> 
>> I think he is right on here.  Those who were prone to be thoughtful about
>> their design would have been anyway.  Those who are not thoughtful about
>> their design will just leave these annotations off… leaving us with no
>> recourse to extend/modify classes.  When people complain, they will add the
>> annotations without actually thinking about the meaning (i.e. stack overflow
>> / the fixit tells me I need to add this word to make the compiler happy).
>> All this does is put framework users at the mercy of the framework writers.
>> 
>> 
>> Finally, this proposal is missing important aspects of the problem space.
>> If we truly want to solve the issue of subclassing, we need to consider all
>> of the common issues which arise.  Looking at the cocoa documentation you
>> will see several types of annotations:
>> 1) This method MUST be overridden
>> 2) This method shou

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

 * What is your evaluation of the proposal?

Strong -1 too.

I can’t count the number of times it save my hours tone able to override 
arbitrary classes and methods. 

Sometimes to simply add log point to understand how the API work. Other times 
to workaround bugs in the library. Or even to extends the library in a way that 
the author did not intent in the first place, but that was perfectly supported 
anyway.

I already see how libraries author will react to that new default. They will 
either don’t care and mark all classes as subclassable, or find to burdensome 
to get subclassability right and prohibit subclassing all classes.


> Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution 
>  a écrit :
> 
>> * What is your evaluation of the proposal?
> A **strong** -1
> 
> First, I have often found that you can’t always predict the way which 
> something will need to be extended.  You think you know, but are then 
> surprised by creative uses.  My favorite features of Swift/Cocoa involve 
> retroactive modeling.
> 
> Second, I don’t think this proposal will achieve its stated objective of 
> forcing people to think about subclassing more.  It will just add confusing 
> boilerplate.  
> 
> Things like Swift optionals work well because they make the (often forgotten) 
> choices explicit in the context that they are used.  In the world of Human 
> Factors, we call it a forcing function.  This proposal has the inverse 
> structure, and will be ineffective, because the “forcing” part of it shows up 
> in a different context (i.e. trying to use a framework) than the decision is 
> being made in (writing the framework).  This type of thinking leads to things 
> like Java and the DMV.
> 
> As Tino said:
>> No matter what the defaults are, good libraries are hard to build, so I 
>> predict this proposal would not only fail in increasing framework quality, 
>> but also will make it much harder for users of those frameworks to work 
>> around their flaws, which are just a natural part of every software.
> 
> I think he is right on here.  Those who were prone to be thoughtful about 
> their design would have been anyway.  Those who are not thoughtful about 
> their design will just leave these annotations off… leaving us with no 
> recourse to extend/modify classes.  When people complain, they will add the 
> annotations without actually thinking about the meaning (i.e. stack overflow 
> / the fixit tells me I need to add this word to make the compiler happy).  
> All this does is put framework users at the mercy of the framework writers.
> 
> 
> Finally, this proposal is missing important aspects of the problem space.  If 
> we truly want to solve the issue of subclassing, we need to consider all of 
> the common issues which arise.  Looking at the cocoa documentation you will 
> see several types of annotations:
>   1) This method MUST be overridden
>   2) This method should NOT be overridden
>   3) This method MUST be called
>   3) This method should NOT be called except by subclasses
>   4) This method should NOT be called except by a method override calling 
> super
>   5) This method MUST call super
>   6) Overrides of this method should NOT call super
> 
> If we are attempting to bring thoughtfulness to the design of classes, I 
> would like to see things be extendable by default, but with annotations that 
> thoughtful framework designers can use to designate how a particular method 
> should be used.  In most cases, it should not explicitly forbid the end user 
> from subclassing, but require them to acknowledge that what they are doing is 
> not intended by the framework. (e.g. "unsafe override func"…).  That would 
> feel 1000x more swifty to me.  Opt-out safety.
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> No. It doesn’t actually solve the problem... and I haven’t actually run into 
> this problem in the real world.
>> * Does this proposal fit well with the feel and direction of Swift?
> No, it gives Swift more of a feeling of busywork and unnecessary boilerplate 
> while failing to achieve its objective.  It goes against the retroactive 
> modeling allowed by other areas of Swift.
> 
>> * If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
> I tend to avoid languages which require this sort of thing.  In other 
> languages that lock things down, there is a need to unlock things soon after 
> (e.g. friend classes).  
> 
> I predict the same thing will happen here.  People will quickly be asking for 
> the ability to patch/override in cases where the framework designer was 
> wrong.  That shows a problem inherent with the design...
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> Read the proposal & discussion.  Read earlier discussions around access 
> control 

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Jean-Daniel Dupas via swift-evolution]

> Le 30 juin 2016 à 01:10, Matthew Johnson via swift-evolution 
>  a écrit :
> 
> 
>> On Jun 29, 2016, at 6:07 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 29 Jun 2016, at 22:15, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> There actually is an answer to this, which is that the core team expects 
>>> 'private' to be the common keyword, and therefore it’s better if you can 
>>> use it at the top level and ignore ‘fileprivate’ altogether in most 
>>> programs.
>> 
>> This makes no sense to me for two reasons:
>> 
>> 1) As I previously said, I don't expect `private` to be the common keyword 
>> if people keep writing types as a main declaration and a set of extensions. 
>> With that style, we'll be using `fileprivate` heavily for properties in the 
>> main declaration.
> 
> It’s clear that *some* people are writing Swift this way.  But I don’t think 
> it is the most common style.  I think it’s more common to put “core” members 
> inside the type declaration.  With that style the need for `fileprivate` is 
> minimized.
> 

All sample code encourage writing extension for protocol, and when writing an 
application, a lot of classes implements delegate protocol. For what I can see 
in my own code, there is a lot of places where I will have to change to 
fileprivate instead of private to make it compile.

>> 
>> 2) If private means only visible to its lexical scope, I would have expected 
>> private top level declarations to be visible to the global scope, which is 
>> equivalent to `internal` for me, no `fileprivate`.
> 
> Files introduce a scope in the same sense that modules do.  
> 
>> 
>> I'm getting more and more confused about SE-0025.
>> ___
>> 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

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

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

[Jean-Daniel Dupas via swift-evolution]

> Le 29 juin 2016 à 21:41, Leonardo Pessoa via swift-evolution 
>  a écrit :
> 
> I actually thought about something like 'public(final)' as it may make
> it clearer the intention to the class (and no new keywords were
> introduced).

I also though about public(final), but it may be confused with "public final" 
which can be used to defined a class final even in the module scope.

> Also I think we should draw a guideline for such naming because there
> are always so many suggestions. Having a guideline would reduce our
> efforts in choosing names.
> 
> L
> 
> On 29 June 2016 at 15:16, Michael Peternell via swift-evolution
>  wrote:
>> Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really 
>> make sense. `internal` declarations are always sealed.
>> 
>> -Michael
>> 
>>> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution 
>>> :
>>> 
>>> Do we really need a new keyword? Since we already have syntax like 
>>> `internal(set)` couldn't we do `internal(unsealed)`, etc.
>>> 
>>> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution 
>>>  wrote:
 On Jun 29, 2016, at 12:15 PM, Michael Peternell  
 wrote:
 
 
> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution 
> :
> 
> +1 for the concept of a "sealed” class.
> -1 for making it default.
 
 Aren't sealed classes already implemented? I think the keyword is `final`..
 So there is nothing left to do :)
>>> 
>>> No, `final` doesn’t allow for any subclassing, but `sealed` allows for 
>>> subclassing within your module (where you can presumably write more 
>>> efficient code based on knowledge of each subclass).
>>> 
>>> - Dave Sweeris
>>> ___
>>> 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
>> 
>> ___
>> 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

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

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

[Jean-Daniel Dupas via swift-evolution]

> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution 
>  a écrit :
> 
> 
>> Am 29.06.2016 um 00:32 schrieb John McCall :
>> 
>> The decision to make class methods polymorphic by default was always 
>> premised on being able to undo that in obvious cases where methods are never 
>> overridden.  Making a class public so that clients can use it shouldn't 
>> cause significant performance degradations just because you forgot to also 
>> write "final".
>> 
>> John.
> 
> I do care about performance. For this reason I don't want a fully dynamic 
> language. I disagree about the "significant performance degradations just 
> because you forgot to also write `final`". I mentioned "performance" in my 
> original post only because it would be the only convincing argument - if 
> there were indeed superior performance when using `final`.
> 
> Of course, dynamic dispatch is much slower than static dispatch. But 
> optimized code does not spend much time dispatching. If a method takes 3 
> seconds to complete, and from that 2 seconds are used for dynamically 
> dispatching method calls, then I would say that it has not been optimized for 
> performance yet. How would such a function look like? The function being 
> dynamically dispatched should probably not be statically dispatched but 
> inlined completely. And for the rare case that the dispatch type really makes 
> all the difference, it's always possible to `final`ize (or `private`ize) some 
> of the used methods.

Swift dynamic dispatch is not Obj-C dynamic dispatch. Talking about the cost of 
dynamic dispatch without real benchmark is premature optimization IMHO.


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

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

[Jean-Daniel Dupas via swift-evolution]

As the IB compiler is able to compile xib into nib without knowledge of the 
actual code, I hardly see how it would guess that a class named Foo in Module 
Bar should now be compiled as Foo and no longer be mangled as Bar.Foo.

Maybe that issue can be mitigated by allowing a @objc(Bar.Foo) annotation and 
use it when migrating existing code.

> Le 28 juin 2016 à 06:56, Charlie Monroe via swift-evolution 
>  a écrit :
> 
> Do you know how would this affect e.g. XIB files or CoreData models where you 
> have the class name + module? If the class was previously marked @objc and 
> now it would be implicitely @objc(ClassName), would it require all XIB files 
> to be updated, or would the XIB compiler be able to deal with it? If the 
> former, than it's a big no for me.
> 
> I'm not a big fan of a change on any account either, though, since it's 
> absolutely not clear that @objc would have this side-effect.
> 
>> On Jun 27, 2016, at 10:26 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Hey, all. An engineer at Apple noticed the following behavior:
>> 
>> 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 3. @objc(Foo) class Foo: NSObject → exposed to Objective-C, unmangled 
>> runtime name
>> 
>> (and 4. @objc class Foo → illegal, classes must have ObjC heritage to be 
>> @objc.)
>> 
>> They specifically observed that (1) and (2) have the same behavior, and 
>> suggested that maybe (2) should be shorthand for (3).
>> 
>> Pros:
>> - There aren't two ways to spell (1).
>> - Removing the mangling (and module uniquing) from the runtime name is 
>> probably one of the most common uses of @objc on a class.
>> 
>> Cons:
>> - It's a source-breaking change, for all that the "@objc" in (2) is 
>> redundant.
>> - For protocols, (1) and (2) are not equivalent, because @objc isn't 
>> inherited there.
>> - Mangling is used to namespace class names at run time; if you drop that, 
>> the ObjC name should probably have a prefix. (This applies more to 
>> frameworks than apps, though.)
>> 
>> There are probably people who say that last con applies to the generated 
>> header as well: we shouldn't put (1) or (2) into the generated header 
>> because the ObjC name might conflict with another class at compile time. 
>> This is valid, but probably too drastic a change at this point.
>> 
>> So, what does everyone think? I'm leaning towards "no change" because it's a 
>> bit subtle and not a big enough win, but if there's widespread support for 
>> this I'll pull it into a proposal.
>> 
>> Jordan
>> 
>> P.S. This is rdar://problem/22296436  for anyone 
>> else at Apple.
>> ___
>> 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

___
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.

[Jean-Daniel Dupas via swift-evolution]

Maybe we can prohibit it in Swift function declaration, and allow it only when 
importing native code.

As David, I don’t see any compelling reason to allow such construct in Swift.

> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution 
>  a écrit :
> 
> When you import ObjC code that has no nullability annotation, IUO make sense 
> since:
> 
> - they can be checked against nil
> - typically, most values in APIs are nonnull (looking at Foundation, for 
> example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark entire 
> regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
> 
> Importing them as optionals would make it really hard to work with the code - 
> whenever you get a value, it's an optional, even in cases where it makes no 
> sense and adding ! to unwrap the optional is not a great solution. And the 
> other solution is to use guards everywhere.
> 
> IMHO the IUO is a nice (temporary) solution for using un-annotated code until 
> it is. But the "pressure" should be applied on the ObjC code.
> 
>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist  
>> wrote:
>> 
>> I don’t know about the chances of getting approved, but I think this is 
>> something worth discussing. 
>> 
>> It might just be my ignorance, but I can’t think of a good reason why a 
>> function argument would be force unwrapped. Either it’s non-null and the 
>> caller is expected to unwrap it or it’s nullable and the method is expected 
>> to handle the nil value. So I’m positive to that part of the proposal.
>> 
>> As to what we should do with the generated interfaces of Objective-C code 
>> that hasn’t been annotated with nullability, I think that needs input from 
>> more people to find the preferred solution. 
>> 
>> Once that’s been discussed some more, I’d be willing to write up a formal 
>> proposal if you don’t feel like it (assuming the discussion leads somewhere).
>> 
>> - David
>> 
>> 
>>> On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> 
>>> See https://github.com/apple/swift-evolution/blob/master/process.md - you 
>>> would need to make an official proposal and submit it as pull request. But 
>>> given the reaction here, it's unlikely to get approved.
>>> 
>>> Also, the ObjC code without nullability is getting fairly rare - all 
>>> Apple's frameworks are with nullability information (as far as I've 
>>> checked) in macOS 10.12, iOS 10. Third party libraries should be updated to 
>>> use nullability (and most libraries that are maintained already do).
>>> 
>>> 
 On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution 
  wrote:
 
 So, its proposal is dead, or what we must to do to force it to 
 swift-evolution repo on GitHub?
 
> 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
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[Jean-Daniel Dupas via swift-evolution]

> Le 27 juin 2016 à 00:00, Michael Peternell via swift-evolution 
> <swift-evolution@swift.org> a écrit :
> 
>> 
>> Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution 
>> <swift-evolution@swift.org>:
>> 
>> Optional are definitely the best way to represent null when parsing JSON.
>> 
>>> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution 
>>> <swift-evolution@swift.org> a écrit :
>>> 
>>> Just one question: If I have functions
>>> 
>>> json_encode(j: JSON) -> String
>>> and
>>> json_decode(j: String) -> JSON throws
>> 
>> If the string is valid JSON, it return .some() optional, if ti is empty, it 
>> returns .none() optional, and if it is invalid, it throws.
> 
> again, `.none()` is not fully specified. So your answer isn't really an 
> answer to my question. There is

Optional (aka Any?) is a fully defined type.

> let null1: String? = nil
> let null2: Int? = nil
> let null3: Any? = nil
> 
> and null1, null2 and null3 are three different concrete values. You are 
> making it too easy for yourself when you just say `.none()`, without 
> specifying the type you are referring to.
> 
> Also, `let x = nil` does not even compile, for exactly this reason. So again, 
> how do you want to represent a JSON null in Swift?
> 
> let json_null: ... = ... // ???
> let myJSONdict = ["a":2, "b":json_null]

As I said, myJSONdict can perfectly be represented as a [String:Any?] 
dictionary.

> -Michael
> 
>> 
>>> what should be the type of JSON? What should '{"a":2,"b":null}' decode to?
>> 
>> Dictionary<String, Any?>
>> 
>>> What should the type of the JSON null value be in Swift?
>> 
>> Optional.none() 
>> 
>>> I think String and String? and String??? are wrong in this case.
>>> 
>>> I'm not saying that I'm convinced that NSNull() is the best way to 
>>> represent null in this case. I just want to explain the use case that I was 
>>> thinking of.
>> 
>> I hardly can think of a better use case than parsing JSON to demonstrate 
>> than Optional are a far better solution to represent a null value than 
>> NSNull.
>> 
>>> -Michael
>>> 
>>>> Am 26.06.2016 um 19:53 schrieb David Rönnqvist via swift-evolution 
>>>> <swift-evolution@swift.org>:
>>>> 
>>>> I'm not convinced that Swift needs more than on way of representing the 
>>>> lack of a value. As far as I've understood (and remember), NSNull main 
>>>> reason to exist is that it's an actual object and won't for example 
>>>> terminate array literals. From what I've observed of people who are new to 
>>>> Objective-C, NSNull is a big surprise, both its general existence but also 
>>>> when to expect it (read check for NSNull to make sure one doesn't crash) 
>>>> and when not to.
>>>> 
>>>> The way I've imagined that the same problem would be solved in Swift is 
>>>> with an optional, optional value. That is: if a field in a response can 
>>>> either be set or not, that's an optional. If that field can either contain 
>>>> a value or the explicit lack of a value that's another optional:
>>>> 
>>>> let nickname: String?? = "Little Bobby Tables"
>>>> 
>>>> As I see it, this is both safer (requiring that the inner nil value is 
>>>> dealt with), serves as a documentation of when an explicit missing value 
>>>> is expected and when it's not, and is more consistent. 
>>>> 
>>>> I would still expect a newcomer to wonder why there is two question marks 
>>>> in some places, but I'd imagine that that explanation would feel more 
>>>> logical.
>>>> 
>>>> And it's (still) possible (at least in the latest Swift Playground) to 
>>>> safely unwrap both levels:
>>>> 
>>>> if case let name?? = nickname { }
>>>> 
>>>> - David
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> On 24 Jun 2016, at 11:32, Brent Royal-Gordon via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>>> Not really. What is the type of Optional.none? `let empty = 
>>>>>> Optional.none` does not compile, it says "Generic parameter 'Wrapped' 
>>>>>> could not be inferred". NSNull() is a unique concrete value, and it's 
>>>>>> c

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[Jean-Daniel Dupas via swift-evolution]

Optional are definitely the best way to represent null when parsing JSON.

> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution 
>  a écrit :
> 
> Just one question: If I have functions
> 
> json_encode(j: JSON) -> String
> and
> json_decode(j: String) -> JSON throws

If the string is valid JSON, it return .some() optional, if ti is empty, it 
returns .none() optional, and if it is invalid, it throws.

> what should be the type of JSON? What should '{"a":2,"b":null}' decode to?

Dictionary

> What should the type of the JSON null value be in Swift?

Optional.none() 

> I think String and String? and String??? are wrong in this case.
> 
> I'm not saying that I'm convinced that NSNull() is the best way to represent 
> null in this case. I just want to explain the use case that I was thinking of.

I hardly can think of a better use case than parsing JSON to demonstrate than 
Optional are a far better solution to represent a null value than NSNull.

> -Michael
> 
>> Am 26.06.2016 um 19:53 schrieb David Rönnqvist via swift-evolution 
>> :
>> 
>> I'm not convinced that Swift needs more than on way of representing the lack 
>> of a value. As far as I've understood (and remember), NSNull main reason to 
>> exist is that it's an actual object and won't for example terminate array 
>> literals. From what I've observed of people who are new to Objective-C, 
>> NSNull is a big surprise, both its general existence but also when to expect 
>> it (read check for NSNull to make sure one doesn't crash) and when not to.
>> 
>> The way I've imagined that the same problem would be solved in Swift is with 
>> an optional, optional value. That is: if a field in a response can either be 
>> set or not, that's an optional. If that field can either contain a value or 
>> the explicit lack of a value that's another optional:
>> 
>> let nickname: String?? = "Little Bobby Tables"
>> 
>> As I see it, this is both safer (requiring that the inner nil value is dealt 
>> with), serves as a documentation of when an explicit missing value is 
>> expected and when it's not, and is more consistent. 
>> 
>> I would still expect a newcomer to wonder why there is two question marks in 
>> some places, but I'd imagine that that explanation would feel more logical.
>> 
>> And it's (still) possible (at least in the latest Swift Playground) to 
>> safely unwrap both levels:
>> 
>> if case let name?? = nickname { }
>> 
>> - David
>> 
>> Sent from my iPad
>> 
>> On 24 Jun 2016, at 11:32, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
 Not really. What is the type of Optional.none? `let empty = Optional.none` 
 does not compile, it says "Generic parameter 'Wrapped' could not be 
 inferred". NSNull() is a unique concrete value, and it's compatible with 
 Objective C, NSObject and AnyObject. We could of course use 
 `Optional.none`, but someone else may use 
 `Optional.none` instead. The extra type information is just 
 misleading in this case.
>>> 
>>> If you want a single, unique value, use `()`.
>>> 
>>> But I'm not sure why you wouldn't just make this member an Optional in 
>>> the first place. Is there some reason that wouldn't be suitable?
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> 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
> 
> ___
> 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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Jean-Daniel Dupas via swift-evolution]

> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution 
>  a écrit :
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?
> 
> — E

What I like is the possibility to iterate over a filtered list using a ‘single’ 
statement, not the keyword itself. If you propose to replace where by something 
less confusing, or add other keywords, I’m all for it.


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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Jean-Daniel Dupas via swift-evolution]

-1 for the removal.

When I read code, I find it far more visible that a loop is over a filter list 
when the filter clause is on the same line, than when the filter clause is 
inside the loop.

Having to read the full content of the loop to determine if the list is 
filtered or not is not an improvement IMHO.

Moreover, I find it far cleaner to use the where clause that having to remember 
than I have to use the lazy accessor to avoid a performance hit.

> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
>  a écrit :
> 
>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
>> Repos" folder and did the same search. Among the 15 repos in that folder, a 
>> joint search returned about 650 hits on for-in (again with some false 
>> positives) and not a single for-in-while use.
>> 
>> -- E
> 
> Not to undermine this fact, but I believe the fact that `where` can be used 
> in a for loop is not widely known. I didn't know about it until about a month 
> ago (haven't really read much docs, but most people don't either).
> 
> But after I found out about it, I started using it and it IMHO improved 
> readability of my code. Not by much, but it's the little things that make you 
> smile, right?
> 
> Many people here argument that `where` is a Swift speciality and needs to be 
> learned by the developer - the alternative is to teach the person what's the 
> proper alternative - that using .filter can have performance impact and that 
> the *correct* way is to use guard within the for loop. And that's IMHO much 
> worse than teaching a person about using `where` within a for loop.
> 
>> ___
>> 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

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

Re: [swift-evolution] [Proposal] Add support for compile-time function execution

[Jean-Daniel Dupas via swift-evolution]

> Le 9 juin 2016 à 01:41, Alexander Momchilov via swift-evolution 
>  a écrit :
> 
> Preface: I know this is likely a large undertaking to implement, but I think 
> it's worth it.
> 
> In addition to the typical compiler optimization of constant math 
> expressions, some languages (such as D and C++) have support for running 
> arbitrary functions at compile time 
>  (with some 
> constraints).
> 
> I see many advantages of this:
> On iOS/OS X: it could precompute the UI and app initialization logic 
> (wherever possible) to speed app load times

I can’t see how it would speed up app launch time. You still all have to 
allocate and init all UI objects, especially as they are opaque objects and 
can’t be precomputed.

> It can significantly speed up the initialization of applications with large 
> static properties. E.g. large constant Dictionaries could be precomputed.
> You could keep complex math expressions (including custom functions) in their 
> unevaluated form, without the pressure to precompute them elsewhere and 
> hardcode in the result.
> Dynamic programming: expensive look-up tables could be precomputed. These 
> wouldn't necessarily be large in size, but if their elements are especially 
> expensive to compute, there would be a huge advantage to precomputing them.
> 
> What do you guys think? Can you think of any other useful applications? Would 
> it be worth the implementation effort?
> 
> - Regards,
> Alexander Momchilov
> ___
> 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

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

[Jean-Daniel Dupas via swift-evolution]

> Le 8 juin 2016 à 02:21, Jordan Rose via swift-evolution 
>  a écrit :
> 
>> 
>> On Jun 7, 2016, at 12:49, Michael Peternell via swift-evolution 
>> > wrote:
>> 
>>> 
>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution 
>>> >:
>>> 
 On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
> I disagree. We are discussing how to annotate a function in some way so 
> that the compiler knows that the code following it will never be executed 
> *and* so a human who reads the declaration knows that it does not return. 
> “Never" is a poor choice for that. Never what? Never return? Never use 
> this function? Never say never again? 
 
 "Never return". That's why it's in the return type slot, right after the 
 `->`. If you read it out loud, you'll read "returns Never", which is 
 exactly correct.
 
 NoReturn, on the other hand, does *not* read well in that slot: "returns 
 NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
 no sense whatsoever *as a type name*.
>>> 
>>> But it’s *not* a type. You’ll never have an instance of it. Since it’s not 
>>> a type name, it doesn’t make sense that it needs to look like one. What it 
>>> is doing is telling you something about the behavior of the function 
>>> itself, not its return value. Its return value, if there were one, is 
>>> irrelevant, since the function, by its very nature, will never even get to 
>>> the point where it would return it. Either it’s going to kill the app via a 
>>> fatalError or something, or we have something like dispatch_main() which 
>>> will keep executing until the program stops, and one way or another, it 
>>> won’t return.
>>> 
>>> For that reason, frankly, I don’t understand why we want to change this 
>>> from being an attribute, which seems to me the more natural and logical 
>>> choice to describe this behavior. If we *do* have to change it, though, 
>>> NoReturn conveys the most clearly to the reader what it does.
>> 
>> +1 for @noreturn
>> We don't have to change it.
>> We have to keep it.
> 
> I strongly agree. Just because it can be modelled as a type doesn’t mean it’s 
> the best way to represent the concept. It feels like uniformity for 
> uniformity’s sake.
> 
> func fatalError() -> Never
> 
> @noreturn func fatalError()
> 
> The first one probably isn't too hard to explain to a learner. The second one 
> probably doesn’t need an explanation.

+1 for keeping it as it is for the same arguments and many other arguments 
already details previously, like telling the function can return something that 
does not exists is not the same that telling it does not return or the fact 
that you can’t expect to code it purely in the standard library using type if 
you want to be able to warn on unreachable code let the compiler optimize based 
on the fact the function never returns (and does not return never).


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

Re: [swift-evolution] Make access control private by default.

[Jean-Daniel Dupas via swift-evolution]

> Le 23 mai 2016 à 23:21, Knut Lorenzen via swift-evolution 
>  a écrit :
> 
> 
>> On 19 May 2016, at 19:18, John McCall  wrote:
>> 
>> That is not at all true.  The dynamic OOP languages do not, as a rule, have 
>> any access control at all.  Java and C# default to package access, which is 
>> analogous to internal.  C++ is, as always, complicated and different.
> 
> Class members are private by default in both Java and C#. As are ivars and 
> selectors in Objective-C (the latter having to be redeclared in the header 
> file for module-wide access). Swift definitely gives greater default scope to 
> class members in comparison to other OOP languages.

On Java, they are package-private, not private by default, which is closer to 
module visibility of swift than private.


> 
> Knut
> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Jean-Daniel Dupas via swift-evolution]

I really don’t like that proposal too.

While I can understand why it may be useful for list, I find it very confusing 
to allow it in function declaration. 
The motivation do not apply here. You can’t simply remove a parameter or 
reorder that without breaking all code that use that function (even function 
with default parameter as the parameter may be explicitly defined at invocation 
site).

Even in other places (list, enum, …), I think the kind of refactoring describe 
in the motivation is not something that is common enough to introduce that kind 
of syntax change.

And the fact that no alternative was investigated (like allowing new line as 
separator) make me think this proposal is not complete and shouldn’t be 
accepted as is anyway.

Jean-Daniel

> Le 14 mai 2016 à 21:25, Kenny Leung via swift-evolution 
>  a écrit :
> 
> I am against this proposal.
> 
> - I think it makes the code look ugly and incomplete when there is a trailing 
> comma
> - I much prefer the counter-proposal which would allow newline to be the 
> separator for items in a list.
>- in general, it’s much better when you can remove something from your 
> code rather than add something to it
>- this proposal serves the same purpose as allowing the trailing comma
> 
> -Kenny
> 
> 
>> On May 10, 2016, at 11:53 AM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
>> begins now and runs through May 16. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> 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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

[Jean-Daniel Dupas via swift-evolution]

> Le 10 mai 2016 à 18:38, Rick Ballard via swift-evolution 
>  a écrit :
> 
> 
>> On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev 
>> > wrote:
>> 
>> 
>>> On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution 
>>> > wrote:
>>> 
>>> +1 to `swift package` being a little too verbose. However, I like the 
>>> alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I 
>>> have already been referring to the package manager as SPM, so IMO that name 
>>> does not lose out on any clarity while also allowing it to be terse enough 
>>> for every day use. 
>>> 
>>> I would not be against having both `spm` and `swift package` as Honza 
>>> suggested.
>> 
>> + 1 to the proposal in general and also to adding the `spm` alias.
> 
> Question for those of you who are advocating for a "spm" alias: Do you have a 
> strong argument / preference for "spm" vs "swiftpm"? Personally I have been 
> abbreviating the project as "swiftpm" and not "spm" when I talk about it, and 
> have been trying to push that as the preferred abbreviation. "spm" is a few 
> less keystrokes, but is a much more generic, less googleable name; out of 
> context, it's impossible to know what it refers to. Once the project gets 
> enough mindshare, like "npm" has, that might be less of an issue, but I still 
> personally prefer the more descriptive "swiftpm". Thoughts?

I prefer swiftpm because I have enough three letters tools on my machine that I 
never know what they do without having to open the man page. Having an explicit 
name will reduce the chance of conflict with other tools and greatly simplify 
its discovery.

And for those who think this is a too long name, creating a shorter alias in 
any shell is relatively easy.



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

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Jean-Daniel Dupas via swift-evolution]

Is this is a plist like construct, couldn’t it simply be declared as [NSString: 
AnyObject] ? As we are talking about removing implicit cast, forcing the user 
to use NSString explicitly for API that need a NSDictionary is probably not a 
problem ?


let userInfo: [NSString: AnyObject] = [
kSomeStandardKey: self.name, // a String
kAnotherKey: self.childNames // an Array of Strings
]
NSNotificationCenter.default().postNotificationName(MyNotification, self, 
userInfo)


> Le 30 avr. 2016 à 02:32, Jordan Rose via swift-evolution 
>  a écrit :
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md]
>  
> 
> 
> I’m a little concerned about the affect this has on “plist literals”. 
> Specifically, I can no longer construct a dictionary like this:
> 
> let userInfo: [String: AnyObject] = [
>   kSomeStandardKey: self.name, // a String
>   kAnotherKey: self.childNames // an Array of Strings
> ]
> NSNotificationCenter.default().postNotificationName(MyNotification, self, 
> userInfo)
> 
> The fix isn’t that hard—just add “as NSString” or “as NSArray”—but it is a 
> bit of extra noise that we currently don’t have. If the type checker can 
> still offer that fix-it, then I’m not sure we’d actually get any compiler 
> simplification out of it…although I suppose it might make the happy path 
> faster.
> 
> The CFString issue Jacob brought up is also a little unfortunate, although 
> that’s about the direction that already requires an explicit coercion. But 
> this probably affects calling CF functions that take CFStrings, since IIRC we 
> don’t treat that the same as NSString at the moment, and CFArray will never 
> have generics.
> 
> Of course, I’ve been out of the Cocoa community for a while now, so I don’t 
> really have a sense of how often this comes up in practice, and how much the 
> explicit coercion costs (psychologically). So I’m with Brent: do we have 
> information on the changes needed for real-world projects?
> 
> Jordan
> 
> 
>> On Apr 26, 2016, at 13:54, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0072: Fully eliminate implicit bridging conversions from 
>> Swift" begins now and runs through May 2. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md
>>  
>> 
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Idea] Allow more operators as custom operators

[Jean-Daniel Dupas via swift-evolution]

> Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution 
>  a écrit :
> 
> & (as a prefix operator), ->, ?, and ! (as a postfix operator)
> 
> This is the list of built-ins that look like operators, but are banned from 
> use as Swift custom operators.
> 
> We can review that list.
> 
> `&` reserved as a prefix operators for a reason. It marks a variable use as 
> `inout`, which currently cannot be done by any Swift operator function.
> 
> Other three don't have such justification.
> 
> `->`, `?` and `!` are used in types, but they are mostly unambiguous in 
> expressions.
> 
> The only use of `!` in expressions can be rewitten as a built-in operator 
> function:
> postfix func !  (left: T!) -> T
> 
> `?` is used in optional method calls:
> a.method?(b)
> A parallel proposal is going to remove such syntax from Swift, so this will 
> not be a problem.
> 
> `?` is also used in patterns:
> if case x? = optional { ... }
> 

While the use is unambiguous for the compiler, I’m not sure it’s going to be 
unambiguous for code readers. Having the same operator meaning different things 
depending the context is a bad idea IMHO.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jean-Daniel Dupas via swift-evolution]

> Le 24 mars 2016 à 06:13, Chris Lattner via swift-evolution 
>  a écrit :
> 
> 
> 
> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution 
>  wrote:
>> Per Doug’s email, the core team agrees we should make a change here, but 
>> would like some bikeshedding to happen on the replacement name for private.
> 
> What we do with private setters is orthogonal from this proposal, so I’m 
> going to ignore it in this thread.  After SE-0025 is resolved, it would be 
> great to have another thread/proposal that discusses reskinning private(set) 
> - presumably as just a modifier on the setter.
> 
> Similarly, this proposal has nothing to do with “protected” or any other type 
> based access control, so I don’t delve into that at all either.
> 
> I’ve seen several proposals that seem promising:
> 
> On Mar 14, 2016, at 5:49 PM, James Berry  wrote:
>> I like fileprivate, if that’s the only change. On the other hand, if we want 
>> to consider a broader change, what about:
>> 
>>  private symbol visible within the current declaration 
>> (class, extension, etc).
>>  private(module) symbol visible within the current module.
>>  private(file)   symbol visible within the current file.
> 
> I love how this establishes a family with different levels of access control, 
> and unites them under the idea of "levels of being private”.  I also like how 
> people would commonly only ever write public and private (because 
> “private(module)” is the default, and "private(file)" is obscure).  However, 
> parenthesized modifiers that take a keyword (as opposed to an identifier) are 
> a bit weird and awkward, so it would be nice to avoid them if possible.
> 
> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution 
>  wrote:
>> public
>> private-module
>> private-file
>> private
> 
> This follows the same sort of structure as James’ proposal, without the 
> parens.  It has the same advantages, but trades them with hyphenated decl 
> modifiers.  We don’t do that, but it is a good direction.
> 
> How about we continue this trend, and follow other existing Swift keywords 
> that merge two lowercase words (associatedtype, typealias, etc), and use:
> 
>   public
>   moduleprivate
>   fileprivate
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.
> 
> What do you all think?
> 
> -Chris


I like the way it goes,  but I don’t like the nospacebetweenwords convention. 
module_private and file_private look better IMHO.




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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jean-Daniel Dupas via swift-evolution]

> Le 19 mars 2016 à 15:35, Dany St-Amant via swift-evolution 
>  a écrit :
> 
> 
>> Le 15 mars 2016 à 09:07, Ilya Belenkiy via swift-evolution 
>> > a écrit :
>> 
>> These names are very uniform, and the context is immediately clear, but they 
>> are very long. The 2 most commonly used (and spelled out) would be 
>> access(global) and access(scope), public and private are much shorter and 
>> are well established terms of art.
> 
> An option which goes against Swift being as explicit as possible is to 
> support abbreviated scope, in addition to the full name:
> 
> access(g)
> access(m)
> access(f)
> access(s)
> 

Even knowing about what we are talking about, I got a hard time understanding 
what each option means.
Using single letter name is utterly confusing and unreadable.

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