Re: [swift-evolution] #pragma

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

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

> 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

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

> 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

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

> 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

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

> 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 :( > >

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

> 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

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

> 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

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

> 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

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

> 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

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

> 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

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

> 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

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

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

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

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

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

> 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,

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

very 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 20

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

* 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

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

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

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

> 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),

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

> 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

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

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)

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

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

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

> 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 definite

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

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) ->

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

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

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

-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

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

> 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,

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

> 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

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

> 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

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

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

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

> 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

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

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] = [

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

> 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

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

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

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

> 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