[swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

Hi all, Dynamic dispatch of methods through AnyObject is a source of implementation complexity, has many known bugs which we are not going to fix, and no longer makes sense now in an id-as-Any world; AnyObject is not the ‘common currency’ type for arbitrary Objective-C objects anymore. I

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

sure of any other method to accomplish our goals here. > > > > Jon Shier > >> On Oct 24, 2017, at 6:02 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi all, >> >> Dynamic dispatch of methods throug

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

Hull <jh...@gbis.com> wrote: >>> >>> I would feel better about it if String gained a lot of the utility of >>> NSString (so that we don’t have to go to NSString all the time for methods) >>> >>> Thanks, >>> Jon >>> >>>>

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

tring all the time for methods) > > Thanks, > Jon > >> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi, >> >> Members of NSString, except those defined in Foundation, are availa

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

>>> isEqual, some underlying implementation is changed and equality works >>> properly (or well enough for this use). I’m happy to get rid of this hack, >>> but I’m not sure of any other method to accomplish our goals here. >>> >>> >>>

[swift-evolution] Pitch: Member lookup on String should not find members of NSString

Hi, Members of NSString, except those defined in Foundation, are available on values of type String. For example, extension NSString { @objc func foo() {} } let s: String = “hello” s.foo() We don’t do this for any other bridged types, for instance NSArray methods are not imported as Array

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

You can implement an @objc protocol with an optional requirement, and make NSObject conform to it. Slava > On Oct 24, 2017, at 4:05 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Oct 24, 2017, at 5:02 PM, Slava Pestov via swift-evolution >> &l

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Paul, Thanks for reviewing the proposal! > On Dec 20, 2017, at 9:21 PM, Paul Cantrell wrote: > > A concern: how would a library author reason about, and check for bugs in, > the combinatorial explosion of old and new implementations that could exist > simultaneously

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 20, 2017, at 10:17 PM, Adam Kemp via swift-evolution > wrote: > > Should there be some kind of diagnostic if you have an @abiPublic definition > that is never referenced by any @inlinable function? I can imagine that there > might be tools to check that a

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 20, 2017, at 10:34 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> Perhaps a diagnostic like this would cause problems if you started with an >> @inlinable function that called an @abiPublic function and then in a >>

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Brent, > On Dec 20, 2017, at 9:35 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I concur. If we don't care about its ungainly size, the blindingly obvious > solution would be `@inlineCallable`. Another solution might be to declare the > symbol with a

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution > wrote: > > Rather than expand local function syntax why not deprecate local functions > completely I don’t think at this point such a drastic change to the language is likely to happen.

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 10:27 PM, Howard Lovatt wrote: > > > Closures cannot replace all uses of local functions. Local functions can be > > recursive, and have a generic parameter list. > > My response would be add these featurtes to closures, it will make closures >

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 9:53 PM, Howard Lovatt via swift-evolution > wrote: > > It would be easy to provide a fixit. That is still a source breaking change that requires migration, though. > How often are they actually used? I rarely use them and all my use cases >

Re: [swift-evolution] Making capturing semantics of local

> On Oct 27, 2017, at 10:51 AM, Mike Kluev wrote: > > On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov > wrote: > > Closures cannot replace all uses of local functions. Local functions can be > recursive, and have a generic

Re: [swift-evolution] Making capturing semantics of local

much pain. Slava > > The reason for showing code above is to demonstrate that the compiler could > do this (in fact it could do better) - I am not suggesting anyone uses the > above! > > -- Howard. > > On 28 October 2017 at 10:01, Slava Pestov via swift-evolution >

Re: [swift-evolution] Making capturing semantics of local

t to Apple. > > Jonathan > >> On Oct 27, 2017, at 12:29, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I mean, we could remove a lot of language features without giving up turing >> completeness. But I’ve persona

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

Hi Hooman, Since the protocol P is not class-bounded, the requirement can be witnessed by a protocol extension method which re-assigns ‘self’: protocol Initable { init() } extension P where Self : Initable { mutating func f(_ x: Int) -> Int { self = Self() return x } } class C :

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 12:42 PM, Paul Cantrell wrote: > > 1. Presumably the portions of A inlined into B and C remain sensitive to the > version-specific memory layout of A? Or will ABI stability mean that the > compiler can magically rearrange memory offsets in

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Chris, Thanks for reviewing the proposal! > On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution > wrote: > >> On Dec 20, 2017, at 4:19 PM, Ted Kremenek > > wrote: >> >> The review of "SE-0193 -

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 9:33 AM, Tony Parker via swift-evolution > wrote: > > public > public(inlinable) > public(external) // *where we define external to be what abiPublic is now — > more bike shedding welcome I think the downside is that public(external) or

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 11:05 AM, Greg Titus via swift-evolution > wrote: > > I come from a perspective similar to Johannes, in that: for my work we are > interested in the performance improvements of cross-module optimization and > specialization but we regularly

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 9:55 AM, Chris Lattner wrote: > When and if we add private cases to enums, we’ll need to be able to associate > an availability range with an “exhaustive” marker. When/if that happens, > then yes, we should do so through @available(exhaustive:

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 7:09 PM, Xiaodi Wu wrote: > > On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner > wrote: > >> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu > > wrote: >>

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:50 AM, Johannes Weiß wrote: > > totally agree that these attributes are necessary, they should be in Swift as > soon as we bike shedded the right name. But to prevent them from being placed > everywhere without thinking I propose to introduce

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution > wrote: > > > On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution > > wrote: >> >> What are your thoughts on `final switch`

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

Hi Dave, The broader problem is being considered holistically, and we’re designing and implementing various pieces of the solution as part of the ABI stability effort for Swift 5. Some of these pieces impact the language, hence you’ll be seeing some evolution proposals. Non-exhaustive enums is

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

Hi Thomas, I see what you mean now. I think in this case I would prefer to just spell this as ‘switch x { … unknown: … }’ vs ‘switch x { … default: … }’. But yes, a few people have signaled support for such a feature and I think it’s worth discussing. Slava > On Dec 23, 2017, at 4:27 PM,

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution > wrote: > > why can’t we just remove inlineable functions from ABI altogether? if the > argument is that app code won’t be able to take advantage of improved > implementations in future library versions

Re: [swift-evolution] namespacing protocols to other types

There was a proposal to allow protocols to be nested inside types at one point but it didn’t move forward. Basically, if the outer type is a non-generic class, struct or enum, there’s no conceptual difficulty at all. If the outer type is a generic type or another protocol, you have a problem

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 8:33 PM, Howard Lovatt wrote: > > I was making two seperate points: 1. Annotating which parts of a public APIs > are stable should not be necessary and 2. Inlining should be left to the > compiler. > > Point 1: If you had a module system that

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution > wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md > >

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Sure, users download new apps more often than they download new OSes, but you’re basically arguing against dynamic linking at this point. If everything was statically linked, vendors would not be able to ship security updates, etc. Slava > On Dec 24, 2017, at 8:46 PM, Kelvin Ma

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Johannes, Thanks for reviewing this proposal! > On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution > wrote: > The library I'm working on will presumably never have stable ABI as you'd > naturally build it with your application. However we also don't

Re: [swift-evolution] [Pitch] @static imports

Hi Karl, This is an interesting idea and part of something we would like to explore in the future, which is resilience domains that span more than one module. However keep in mind that in the current design, resilience is something you opt into when building a library, with a compiler flag. If

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Xiaodi, Thanks for taking the time to look over the proposal. > On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution > wrote: > > Does this proposal fit well with the feel and direction of Swift? > > Yes, with a caveat. It seems a little unfortunate that

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Nevin, Thanks for taking the time to review the proposal! > On Dec 20, 2017, at 7:08 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Alternatively, since the “@abiPublic” attribute allows objects to be used by > inlined code, why not spell it

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Tony, Thanks for the review! > On Dec 20, 2017, at 8:09 PM, Tony Allevato via swift-evolution > wrote: > > A related question (with some background): My assumption is that conditional > compilation directives (e.g., #if DEBUG) are resolved *before* an @inlinable

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Thanks for the review, Kelvin. > On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution > wrote: > > it makes sense to have @abiPublic on private and fileprivate declarations too > and i hope this gets added, because private and fileprivate are tools for > code

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

> On Jan 3, 2018, at 5:33 PM, Hooman Mehr wrote: > > Thank you Slava, it is a very insightful answer. > > It also reveals a potential source for hard to track bugs. To make it easier > to see, lets add state to class C: > > class D: C { var state = 0 } > > var d = D() //

<    1   2   3