Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution > wrote: > > Replace isUniquelyReferenced by > isUniquelyReferencedUnsafe and remove the NonObjectiveCBase > class from the standard library. > > So we’ll have: -

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 9:41 PM, Arnold wrote: > > > > Sent from my iPhone > >> On Jul 16, 2016, at 9:23 PM, Andrew Trick wrote: >> >> >>> On Jul 16, 2016, at 9:17 PM, Arnold wrote: >>> >>> >>> >>>

Re: [swift-evolution] Fixing modules that contain a type with the same name

For what it’s worth, I renamed OrderedSet to SortedSet in the Swift 3 version of BTree, so the original instance of this issue is hopefully no more. Prohibiting modules from containing a symbol of the same name would require a mass renaming of many microframeworks. Besides BTree, I also have

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

Regards (From mobile) > On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The second review of "SE-0117: Default classes to be non-subclassable > publicly" begins now and runs through July 22. The proposal is

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Regards (From mobile) > On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution > wrote: > > Wrong thread ;) If you think it’s ill-prepared than provide some feedback > instead of just watching and waiting to throw negative feedback during review >

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 8:45 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 8:36 PM, Arnold wrote: >> >> Thank you for the feedback. Answers online. >> >> Sent from my iPhone >> >>> On Jul 16, 2016, at 7:38 PM, Andrew Trick

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Sent from my iPhone > On Jul 16, 2016, at 9:23 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 9:17 PM, Arnold wrote: >> >> >> >> On Jul 16, 2016, at 8:45 PM, Andrew Trick wrote: >> >>> On Jul 16, 2016, at 8:36 PM,

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

> On Jul 16, 2016, at 9:17 PM, Arnold wrote: > > > > On Jul 16, 2016, at 8:45 PM, Andrew Trick > wrote: > >> >>> On Jul 16, 2016, at 8:36 PM, Arnold >> > wrote:

Re: [swift-evolution] Fixing modules that contain a type with the same name

To be clear, I think that you should be allowed to have a symbol that has the same name as the module. I was talking about that alternative because other people on this thread preferred it, but this does not reflect my opinion at all. As Károly writes, one very big reason to dislike it is that

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

> On 2016. Jul 16., at 16:45, Karl via swift-evolution > wrote: > Sorry to mail 3 times in a row, but as I finished I remembered a concrete > example of where sealed protocols would be helpful: > > UIKit has a UITextInput protocol, which is used by custom text object

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

`isUniqueReferencedNonObjC` is useful if our storage could be other a native Swift class or an objective-c class instance. An example of this is Array's storage: It could either be a native Swift class instance or if the array was bridged from cocoa an NSArray instance. Before we write to the

Re: [swift-evolution] Fixing modules that contain a type with the same name

I've been wanting to do this kind of overhaul for the last 6 months. My original spitball thread is here http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394 and I have a draft of a proposal that I hope to put out soon that I can let you view (or even coauthor if you desire) if

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

Regards (From mobile) > On Jul 17, 2016, at 4:24 AM, L. Mihalkovic > wrote: > > > Regards > (From mobile) > >> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The second

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 7:56 PM, Jose Cheyo Jimenez wrote: > I think you can simplify this proposal by just saying something like this > and give a couple of examples that are easy to follow: > > Disallow explicit public access modifier on non-protocol-conforming type >

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

> On Jul 16, 2016, at 8:36 PM, Arnold wrote: > > Thank you for the feedback. Answers online. > > Sent from my iPhone > > On Jul 16, 2016, at 7:38 PM, Andrew Trick > wrote: > >> >>> On Jul 16, 2016, at 6:46 PM, Arnold

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Thank you Dmitri for your feedback. Updated draft below. https://github.com/aschwaighofer/swift-evolution/blob/remove_nonobjectivecbase/proposals/-remove-nonobjectivecbase.md Remove NonObjectiveCBase and replace isUniquelyReferenced by isUniquelyReferencedUnsafe Proposal: SE-

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Can you elaborate? What understanding of extensions is lacking in this proposal? On Sat, Jul 16, 2016 at 22:30 L. Mihalkovic via swift-evolution < swift-evolution@swift.org> wrote: > > Regards > (From mobile) > > On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution < >

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Thank you for the feedback. Answers online. Sent from my iPhone > On Jul 16, 2016, at 7:38 PM, Andrew Trick wrote: > > >> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution >> wrote: >> >> Replace isUniquelyReferenced by >>

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

Updated proposal: Remove NonObjectiveCBase and isUniquelyReferenced Proposal: SE- Author: Arnold Schwaighofer Status: Pitch Review

Re: [swift-evolution] Fixing modules that contain a type with the same name

I don't see anything source breaking here. I'm fairly sure it's 100% additive and will therefore wait for after Swift 3. > On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution > wrote: > > There is about 2 weeks left for source-breaking proposals, and this

Re: [swift-evolution] Fixing modules that contain a type with the same name

There is a lot of potential for it to be a breaking change. Currently, you can do module qualification with Module.Symbol. This causes problems. The two most obvious solutions (change the "operator" between Module and Symbol, or prevent symbols from having the same name as their module) are

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 6:10 PM, David Hart wrote: > This proposal really confuses me. Two comments: > > 1) With the proposal, we loose the ability to use access modifiers on > extensions as a way of grouping members by access. That's a huge loss for > me. > You lose the

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I think you can simplify this proposal by just saying something like this and give a couple of examples that are easy to follow: Disallow explicit public access modifier on non-protocol-conforming type extensions. I think if you only focus on that breaking change then the proposal will have a

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I took some time to overview the whole idea in general, and I must say (surprisingly) that I don't support it myself. * Metatypes are still in the language; it turned out that they *must* remain in the language * The new primary `Type` struct duplicates semantics and interface of metatypes * But

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

> * What is your evaluation of the proposal? > This is improved from the previous iteration. The code example needs updating, as both instances of `open func bar()` should be `public open func bar()` as outlined in the Proposed Design section. > * Does this proposal fit well

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 16.07.2016 um 03:53 schrieb Susan Cheng : > > How about Polar(r: 0, phi: 0) ? > It should all equal with any angles if r == 0. In an earlier post I wrote: > And I would do the „standard equality“ upfront even if there is a custom > implementation > and if the

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

Review link:  https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md * What is your evaluation of the proposal? +1 for the implementation. +0.5 for the concept. I think this is a clean interface for what open should be, and am glad at the

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

H, currently I’m inserting some changes and tweaks into your last gist update. Metatypes are still in the language; it turned out that they must remain in the language Type wraps around metatypes and will provide better maintenance if ever needed, because metatype instantiation will be

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

One more thing to consider. If we had no Type struct/class there would be no way to get the size of a dynamic metatype after SE–0101 and SE–0096. func dynamicType(_ instance: T) -> Metatype MemoryLayout.size We can not check the size of T because then we might end up with the wrong size if

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

> 2016/07/16 14:52、Chris Lattner via swift-evolution > のメール： > > Hello Swift community, > > The second review of "SE-0117: Default classes to be non-subclassable > publicly" begins now and runs through July 22. The proposal is available here: > > >

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Susan, I wrote the former mail in a hurry: the URI example from before is a *false-positive* either and can be handled like the `Polar` example. But the problem with false-negatives are still valid. Example: ```swift func ==(lhs: A, rhs: B) { if(globalBooleanVarIsDayEven) { return

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

> On Jul 15, 2016, at 10:35 PM, Patrick Pijnappel via swift-dev > wrote: > > Isn't half of this done, or something? I seem to remember seeing code about > it, and I think there may even be a hidden switch to enable what is there. > > The parsing code seems to be in

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

> On 15 Jul 2016, at 19:46, Ted Kremenek via swift-dev > wrote: > > Hi everyone, > > Swift 3 has shaped up to be a remarkable release — a product of the > inspiration, ideas, and hard labor many people from across the Swift open > source community. It is now time,

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

> * What is your evaluation of the proposal? +1. Looks much better than the previous version and makes a lot of sense to me. A quick clarification question (I didn’t find any mention of this in the proposal, but I might have missed it): what happens if a class is declared open, but does

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I tried to better describe my alternative solution here . The problem with Mirror is that it can only carry a metatype around and thats it. You may be able to extract it from there and than what? You’ll cast it the old fashion way.

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Like others, I do find the details of this proposal hard to follow. It doesn’t seem like a simpler mental model for developers. However, I also find the current rules around extension access modifiers hard to follow. It’s confusing that “public extension” changes the default for members, when

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

> On Jul 16, 2016, at 12:33 AM, Taras Zakharko via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > +1. Looks much better than the previous version and makes a lot of sense to > me. > > A quick clarification question (I didn’t find

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

> On Jul 16, 2016, at 12:59 AM, Xiaodi Wu via swift-evolution > wrote: > > > * What is your evaluation of the proposal? > > This is improved from the previous iteration. The code example needs > updating, as both instances of `open func bar()` should be

[swift-evolution] [Draft] Harmonize access modifiers for extensions

With the impending withdrawal of SE-0119 and the closing window for (most) source-breaking changes, I thought I'd draft up a proposal to address some of the key points raised in that discussion. The proposed changes are deliberately limited in scope to rationalizing access modifier rules without

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

"open is invalid on declarations that are not also public (see the Alternatives discussion for rationale)." + "If an open class inherits an open method from a superclass, that method remains open. If it overrides an open method from a superclass, the override is implicitly open if it is not

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

> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan wrote: > "open is invalid on declarations that are not also public (see the > Alternatives discussion for rationale)." > > + > > "If an open class inherits an open method from a superclass, that method > remains open. If it

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 1:13 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Have you by any chance meant this? > > You can extend a class, structure, or enumeration in any access context in > which the class, structure, or enumeration is available. Any type members >

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

On Sat, Jul 16, 2016 at 9:09 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Swift has always gone towards making declarations explicit to read. Having > open on thé class declaration makes it so you don't have to go hunting into > its members to see if it contains an

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

It looks like Github does not send notifications. Just in case, I’ve responded here . By the way, I very much like how you recommend to use someType.metatype.staticMethod() and avoid any other usage of metatypes. ​

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

> On Jul 16, 2016, at 9:18 AM, Taras Zakharko wrote: > > >> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution >> > wrote: >> >> I agree with Kevin Ballard on being open by default for methods/

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D Making all extensions public when there is protocol conformance

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I’m responding anything that is related to your last version directly on gist rather than here, because it’s me not understanding a few things of that version. That’s why our main version tackles the whole calculation inside Type rather than splitting it into the Mirror type. I’m totally fine

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

> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution > wrote: > Sent from my iPhone > > On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution > > wrote: > >> Yes, sorry, my point was

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

> On Jul 16, 2016, at 9:05 AM, Jose Cheyo Jimenez via swift-evolution > wrote: > >> * 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 talk about this

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

Have you by any chance meant this? You can extend a class, structure, or enumeration in any access context in which the class, structure, or enumeration is available. Any type members added in an extension have the same default access level as type members declared in the original type being

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

On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 16, 2016, at 11:03 AM, T.J. Usiyan wrote: > > "open is invalid on declarations that are not also public (see the > Alternatives discussion for rationale)." > + > >

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

> On 15 Jul 2016, at 12:46, Haravikk via swift-evolution > wrote: > > >> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution >> > wrote: >> >> To sum this all up, the core team is rejecting this

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

> On 16 Jul 2016, at 16:32, Karl wrote: > > >> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution >> wrote: >> >> What happens if I want an `internal` subclass of an `open` class? > > That should be allowable. You may want

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

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution > wrote: > > I agree with Kevin Ballard on being open by default for methods/ properties > http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ >

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

The problem with Mirror is that it can only carry a metatype around and thats it. You may be able to extract it from there and than what? You’ll cast it the old fashion way. As I may recall I asked the community in the following thread about Hashable ability, which isn’t implementable without

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

Yes, sorry, my point was that this consideration isn't spelled out. Another question is whether or not making a subclass of an open class public by default is what we want. I see why it would be, I just think that it is a wrinkle to default to internal otherwise but not here. On Sat, Jul 16,

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

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

Re: [swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1 Same answers. > On Jul 15, 2016, at 10:54 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1 > > * Is the problem being addressed significant enough to warrant a > change to Swift? > >

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

Sent from my iPhone > On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution > wrote: > > Yes, sorry, my point was that this consideration isn't spelled out. > > Another question is whether or not making a subclass of an open class public > by default is

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

If it’s possible I’d like to withdraw this proposal. I’m convinced by the feedback from the community. Feel free to reject it. ;) --  Adrian Zubarev Sent with Airmail Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution (swift-evolution@swift.org) schrieb: On Jul 13, 2016, at 10:26

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I will now talk about general design, not specific methods or implementation details. This touches SE-0101. The following are niches for metatype-like types: 1. Explicit specialization of functions and expressing specific static types 2. Dynamic dispatch of static methods 3. Passing

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] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> 2016/07/16 21:37、Jean-Daniel Dupas のメール： > >> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution >> > a écrit : >> >> 2016/07/15 16:37、Riley Testut via swift-evolution >

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Dear Saagar, > Am 15.07.2016 um 19:05 schrieb Saagar Jha : > > Equatable, where the == operator is defined, will not let you compare two > things of a different type. This is not true for reference types. Consider the following **bad** (but compiling code): ```swift

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

Swift has always gone towards making declarations explicit to read. Having open on thé class declaration makes it so you don't have to go hunting into its members to see if it contains an open member. Other comments inline: > On 16 Jul 2016, at 14:49, Andre via swift-evolution >

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

What happens if I want an `internal` subclass of an `open` class? On Sat, Jul 16, 2016 at 10:09 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Swift has always gone towards making declarations explicit to read. Having > open on thé class declaration makes it so you

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

In order to prevent false-negatives for reference types, I would like to add a 5th. point to my proposals: 5. Identity (i.e. `===`) should be checked even for reference types upfront and only if it returns `false` the custom `==` function of the developer is executed. This way you cannot

Re: [swift-evolution] Fixing modules that contain a type with the same name

There is about 2 weeks left for source-breaking proposals, and this is going to be one of them. How is progress going? Do you think that you'll have enough time to push it out of the door? Félix > Le 20 juin 2016 à 17:33:03, Paulo Faria a écrit : > > Yeah! I’m working on a

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

> On Jul 16, 2016, at 11:48 AM, Xiaodi Wu wrote: > On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution > > wrote: >> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan >

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

Makes sense. Thanks for clarifying. On Sat, Jul 16, 2016 at 14:17 John McCall wrote: > On Jul 16, 2016, at 11:48 AM, Xiaodi Wu wrote: > On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Jul

Re: [swift-evolution] adding Obj-C syntax to Swift?

Regards (From mobile) > On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution > wrote: > > My reply didn’t go to the list… my apologies… > > On Jul 11, 2016, at 8:19 PM, Ford Prefect > > wrote: > > People say

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Wrong thread ;) If you think it’s ill-prepared than provide some feedback instead of just watching and waiting to throw negative feedback during review process. There is a lot done, but it’s not visible to the public thread yet. Will be soon (by tomorrow I’d guess). Thanks. --  Adrian

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> Am 14.07.2016 um 16:46 schrieb Vladimir.S via swift-evolution > : > > Just +100. One more wise decision from the core team. Thank you for all of > your work. Indeed! Thank you! -Thorsten > >> On 14.07.2016 7:47, Chris Lattner via swift-evolution wrote: >>

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via swift-evolution wrote: > ## Proposed solution > > Replace `isUniquelyReferenced` by > `isUniquelyReferencedUnsafe` and remove the `NonObjectiveCBase` > class from the standard library. Thank you for this

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

On Fri, Jul 15, 2016 at 2:26 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 14, 2016, at 10:58 PM, Charles Srstka > wrote: > > On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >

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

> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution > wrote: > > What happens if I want an `internal` subclass of an `open` class? That should be allowable. You may want some optimised implementations, similar to how Apple used class-clusters in Obj-C. I

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

On Sat, Jul 16, 2016 at 1:48 PM, Xiaodi Wu wrote: > On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan wrote: >> >> "open is invalid on declarations that

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

To me this is reminicent of what is happening with the T.Type / Type story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds. Regards (From mobile) > On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via

[swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

https://bugs.swift.org/browse/SR-1962 # Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe` ## Introduction Remove `NonObjectiveCBase` and replace`isUniquelyReferenced(_ object: T)` by `isUniquelyReferencedUnsafe(_ object: T)`. This will remove