Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 4:02 AM, Xiaodi Wu wrote: > > That is not exactly what Brent was speaking of. We are talking about this > scenario: > > File A: > > ``` > internal struct S { > func foo() { } > } > ``` > > File B: > > ``` > private protocol P { > func foo() > }

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 11:02 AM, Xiaodi Wu wrote: > > Really? I wasn't aware that you could work around the `override` keyword (the > one that's required for classes). How do you do that? By implementing the subclass’s method before the superclass’s. You can try this

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:49 PM, Xiaodi Wu wrote: > > Sorry, I was referring to my original example: S is in a different file from > P and has its own implementation of foo(), and P has its own default > implementation of foo(). I assumed you simplified the example above to

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 1:45 PM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 1:27 PM, Charles Srstka > wrote: >> On Aug 26, 2016, at 11:02 AM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 3:58 PM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 3:43 PM, Charles Srstka > wrote: > > On Aug 26, 2016, at 3:19 PM, Xiaodi Wu > wrote:

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:38 PM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 2:34 PM, Charles Srstka > wrote: >> On Aug 26, 2016, at 2:29 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Keyword for protocol conformance

On Aug 26, 2016, at 3:19 PM, Xiaodi Wu wrote: >> Why? S.foo() is visible throughout the module, but outside this file, >> S.foo() doesn't override anything. Why should it be marked as an `override` >> when, as you say, the generated interface shows no sign of conformance

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:29 PM, Xiaodi Wu wrote: > > I misread your example. You have to run the app *without compiling*; your two > versions of the library have a compatible ABI. The Swift compiler won't > compile your app code, so how's that an example of "working around"

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 3:02 PM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 2:57 PM, Charles Srstka > wrote: >> On Aug 26, 2016, at 2:49 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:34 PM, Xiaodi Wu wrote: > > internal struct S {} > > private protocol P { > func foo() > } > > extension S: P { > func foo() {} > } > > - - - choose “Generated Interface” and you get: - - - > > internal struct S { > } > > > extension S {

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:58 PM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 2:48 PM, Charles Srstka > wrote: >> On Aug 26, 2016, at 2:38 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Renaming for Protocol Conformance

I was just thinking about proposing something like this. +1. Charles > On Aug 22, 2016, at 11:59 PM, Jonathan Hull via swift-evolution > wrote: > > Hi everyone, > > We talked about this before when we were discussing mixins, and there seemed > to be generally

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution > wrote: > > 2016/08/22 14:30、David Cordero via swift-evolution > のメッセージ: > >> >> The problem: >> At the moment, looking at the code of

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 24, 2016, at 1:20 AM, Robert Widmann wrote: > 2016/08/23 20:52、Charles Srstka > のメッセージ: > >>> On Aug 23, 2016, at 10:34 PM, Robert Widmann >>

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 23, 2016, at 10:34 PM, Robert Widmann wrote: > > 2016/08/23 15:29、Charles Srstka > のメッセージ: > >>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution >>>

Re: [swift-evolution] Type-annotated throws

> On Aug 28, 2016, at 3:44 AM, Bouke Haarsma via swift-evolution > wrote: > > On 2016-08-26 15:39:05 +, Félix Cloutier via swift-evolution said: > > Hi all, > > Currently, a function that throws is assumed to throw anything. There was a > proposal draft last

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 23, 2016, at 12:11 AM, Charlie Monroe > wrote: > > I don't see it as sub-par in this example (this actually happened to me): > > @objc protocol Foo { > optional func bar() > } > > class FooImpl: Foo { > func bar() { ... } > } > > Now imagine

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 25, 2016, at 4:15 PM, Vladimir.S via swift-evolution > wrote: > > > let fooIsNSString = foo is NSString // true > > I don't understand. Why is so? On which version of Swift did you try this? > > IBM Swift Sandbox > Swift Ver. 3.0 (Aug 23, 2016) >

Re: [swift-evolution] Keyword for protocol conformance

Is there a reason that adding a “retro” keyword on extensions meant to retroactively apply a protocol is unacceptable? Charles > On Aug 25, 2016, at 6:44 PM, Xiaodi Wu via swift-evolution > wrote: > > Chris, as I wrote above, this idea has been discussed previously

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 25, 2016, at 10:24 PM, Xiaodi Wu wrote: > > Yes, and it's covered in those previous threads. In brief, not all > retroactive modeling involves extending a type: > > * A vendor supplies you with a closed-source library with a struct S that > conforms to standard

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 25, 2016, at 11:48 PM, Xiaodi Wu wrote: > > On Thu, Aug 25, 2016 at 11:05 PM, Charles Srstka > wrote: >> On Aug 25, 2016, at 10:24 PM, Xiaodi Wu > >

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 26, 2016, at 2:22 AM, Xiaodi Wu wrote: > > On Fri, Aug 26, 2016 at 1:53 AM, Charles Srstka > wrote: >> On Aug 25, 2016, at 11:48 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] $self

> On Sep 28, 2016, at 7:48 PM, Jay Abbott via swift-evolution > wrote: > > Sean, yeah that's kind of what I was suggesting for @escaping closures - it > should be the default... but it is a breaking change and as Chris pointed out > that would need extreme

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution > wrote: > > D'erp. I missed that. And that's an unambiguous answer. > > So let me move on to part B of the pitch: I think CharacterSets are broken. > >> Xiaodi Wu: "isn't the problem you're presenting

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

-1. The “default: break” is not only not difficult to write, it clearly communicates the programmer’s intent to only handle a subset of the cases. Without it, it is impossible to know whether that was intended, or by accident. Furthermore, the exhaustiveness by default can catch many mistakes,

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Right. The question is whether we *need* to add stored properties out-of-module, and what the use case for that is. To me it seems that adding them in-module is by far the more common use case, for the purposes of implementing protocols. At any rate, the rewrite option would be a great

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 12, 2016, at 3:07 PM, Karl wrote: > > I disagree. I find the first better in a number of respects (although there > are certainly things you could do to optimise legibility). > > Firstly, I can more clearly see all of the various file errors. I can easily > see

Re: [swift-evolution] private & fileprivate

> On Oct 13, 2016, at 1:25 AM, Jean-Daniel via swift-evolution > wrote: > > I don’t think monitoring the usage of private vs fileprivate is fair. By > default, people will use private until they encounter visibility issues and > discover they need to change to

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> On Oct 14, 2016, at 2:59 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" > begins now and runs through October 18. The proposal is available here: > > >

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 1:26 PM, Joe Groff via swift-evolution > wrote: > > If we move to this on-demand model for @objc-ness, then it seems to me we can > potentially get away from @objc having to be a thing. The constraints on > being representable in ObjC can still

Re: [swift-evolution] Some clarity lost from the great renaming

They can always add the new mapping, and leave the old one there but deprecate it. Charles > On Oct 18, 2016, at 8:51 PM, Hooman Mehr via swift-evolution > wrote: > > Is changing the mapping of Cocoa API considered a source breaking change or > can we report such

Re: [swift-evolution] [Proposal] Factory Initializers

Is there any chance of reviving this? It seems to me that since this would require Swift initializers to be implemented internally in such a way that they can return a value (as Objective-C init methods do), it may affect ABI stability and thus may be germane to the current stage of Swift 4

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution > wrote: > > In Objective-C, asking whether or not an object conforms to a protocol just > cascades in to a bunch of calls to “respondsToSelector”, so it’s also very > painful. This isn’t true; Objective-C

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> On Oct 25, 2016, at 11:38 AM, Jay Abbott via swift-evolution > wrote: > > I mentioned this in passing on a different thread > . > Although it caused some slight confusion when I

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 11, 2016, at 4:42 PM, Braeden Profile via swift-evolution > wrote: > > enum RectSize > { >let height:Int >let width:Int >case small(width: 30, height: 30) >case medium(width: 60, height: 60) >case large(width: 120, height: 120) > } I like

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 13, 2016, at 3:34 AM, Charles Srstka wrote: > >> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution >> > wrote: >> >>> On 12 Oct 2016, at 12:31, Karl via swift-evolution >>>

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 13, 2016, at 3:14 AM, Haravikk via swift-evolution > wrote: > >> On 12 Oct 2016, at 12:31, Karl via swift-evolution >> > wrote: >> >> I very much disagree with the proposal, and all of the things

Re: [swift-evolution] stored properties in extensions (was: associated objects)

*Replace both instances of “class C: P” with just “class C” since the conformance comes in the extension. That’s what I get for writing this quickly. Charles > On Oct 9, 2016, at 3:43 PM, Charles Srstka wrote: > > protocol P { > var foo: String { get } >

Re: [swift-evolution] stored properties in extensions (was: associated objects)

How about a 5th way? 5. Let extensions introduce stored properties, but only in the same module as the type’s definition. Then, the compiler can just take any extensions into consideration when it’s determining the size of the type, just as if the properties had been declared in the type.

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution > wrote: > >> Benjamin: >> >> Implementation wise, weak does *not* currently have the effect of storing >> associated values. It does however mean that any object with weak references >> stays

Re: [swift-evolution] [Proposal] Enums with stored properties

> On Oct 12, 2016, at 4:48 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > Since the definitions of the properties are implementation details, the > generated interface would collapse to the simple list of cases and their > associated

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

Extremely strong +1. I’ve got a bunch of Objective-C-style really long type names of the sort “MyProtocol”, “MyProtocolSomeTypeEnum”, “MyProtocolSomeOptionsEnum”, etc. It would be really nice to make those Swiftier. Charles > On Oct 17, 2016, at 12:59 PM, Karl via swift-evolution >

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On Oct 17, 2016, at 12:47 PM, Jonathan Hull via swift-evolution > wrote: > >> On Oct 17, 2016, at 12:37 AM, Rien > > wrote: >> >> -1. >> >> If an API designer wants to allow access to a “hidden’ member, he

Re: [swift-evolution] Generic types—covariance/contravariance

Yes, please. +1. Charles > On Dec 8, 2016, at 6:45 PM, Braeden Profile via swift-evolution > wrote: > > Has the core team or the community considered the possibility of implementing > covariant/contravariant generic types? It would really be appreciated. > > I

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On Dec 15, 2016, at 4:33 PM, Kevin Ballard wrote: > > The problem with that code isn't that `dynamic` doesn't work for computed > properties. It does; if you mutate the `foo` property, you'll get the KVO > notifications. The problem is you have one property that depends on

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On Dec 16, 2016, at 12:36 AM, Kevin Ballard wrote: > > On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: >>> On Dec 15, 2016, at 4:33 PM, Kevin Ballard >> > wrote: >>> >>> The problem with that code isn't that `dynamic` doesn't work

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

The need to use === is at the root of my problem as well. Charles > On Dec 6, 2016, at 1:30 PM, Андрей Володин via swift-evolution > wrote: > > Been struggling with this kind of problem. My case: I have an array of class > protocol and can’t use my extension that

Re: [swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

> On Dec 15, 2016, at 12:16 AM, Derrick Ho wrote: > > You can currently access swift enums from objective c provided that it is > marked @objc and inherits from Int. Not when I try it: enum MyEnum: Int { case foo = 0 case bar = 1 } @objc var myEnum: MyEnum =

[swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

MOTIVATION: Many Cocoa classes which allow the user to choose from a list of items, such as NSPopUpButton, NSSegmentedControl, and NSTabView, offer the ability to bind the view to an integer or string in the model via KVO, through bindings such as “Selected Tag”, “Selected Index”, “Selected

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:46 PM, Joe Groff wrote: > > Everything *can* be bridged to an object as a result of SE-0116 > ("id-as-Any"), so there's no longer such a thing as a "non-bridgable value > type”. Ah, so that arbitrary Swift types can be stashed in Objective-C userInfo

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 3:09 PM, Joe Groff wrote: > >> On Dec 12, 2016, at 12:59 PM, Charles Srstka > > wrote: >> >>> On Dec 12, 2016, at 2:46 PM, Joe Groff >> > wrote: >>>

[swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

I’ve been trying to figure out the rationale for why the code below behaves the way it does for some time: import Foundation class C: NSObject { dynamic var foo: Int { return 5 } dynamic func bar() -> Int { return 6 } } struct S {} let c = C() let s = S() print(c is

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:12 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > print((c as AnyObject?)?.bar() as Any) // Optional(6) > print((s as AnyObject?)?.bar() as Any) // crash! -[_SwiftValue bar]: > unrecognized selector sent to ins

Re: [swift-evolution] Consolidate Code for Each Case in Enum

> On Jan 9, 2017, at 11:54 AM, Tim Shadel via swift-evolution > wrote: > > enum OneOnOneField: Int { > > var title: String { return "" } > var placeholder: String { return "" } > var image: UIImage { return UIImage() } > > case agenda { > var

Re: [swift-evolution] Update on the Swift Project Lead

Is this really necessary? Charles > On Jan 11, 2017, at 11:18 AM, John Pratt via swift-evolution > wrote: > > You are just going to drop this entire project, that has its name associated > with you, > for a very fierce competitor? > > However capable Ted Kremenek

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On Nov 29, 2016, at 9:52 AM, Adrian Zubarev via swift-evolution > wrote: > > I just showed a direction of what could be possible. > > Personally I think it would be enough if we had this: > > enum MyEnum { > > case a > case b(Int) > case b(Int,

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

I’m thinking more of default values as an alternative to overloaded enum cases. Giving the second parameter a default value equal to whatever the first case would have been assuming would obviate the need for overloaded cases here, and wouldn’t break the ability to leave out the values by

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

> On Dec 5, 2016, at 11:39 AM, Joe Groff <jgr...@apple.com> wrote: > >> On Dec 4, 2016, at 6:46 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The following currently does not work: >> >> protocol P: c

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

> On Dec 4, 2016, at 11:49 PM, Derrick Ho wrote: > > Does the following expression evaluate to true? > > p is AnyObject > > If it does then you may have found a bug. Not only does it evaluate to true, the compiler warns me that "'is' test is always true”. Charles

[swift-evolution] Passing class protocols to functions accepting AnyObject

The following currently does not work: protocol P: class {} class C: P {} func foo(t: T) where T: AnyObject { print("foo") } let p: P = C() foo(t: p) // error: cannot invoke 'foo' with an argument list of type '(t: P)' It seems to me that this ought to have been allowed, since P is

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Dramatically source-breaking, dubious benefit. -1. Charles > On Nov 30, 2016, at 4:40 PM, Erica Sadun via swift-evolution > wrote: > > This pitch is breaking, and should be considered under the phase 1 timeframe. > gist here:

Re: [swift-evolution] [Discussion] Generic protocols

> On Dec 2, 2016, at 12:34 PM, Adrian Zubarev via swift-evolution > wrote: > > I just overlooked that the subsection about generic protocols was inside the > Unlikely section. > > The problem is that I need a way to refer to a function with a specific name. > Plus

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On Dec 19, 2016, at 1:57 PM, Kevin Ballard wrote: > > On Fri, Dec 16, 2016, at 06:30 AM, Charles Srstka wrote: >>> On Dec 16, 2016, at 12:36 AM, Kevin Ballard >> > wrote: >>> >>> On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: >

Re: [swift-evolution] URL Literals

> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution > wrote: > > I would like to be able to create a URL literal that is compile-time > checked for correct format. This would help avoid code like this: > >let url: URL = URL(string:

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:45 PM, Matthew Johnson wrote: > > Sure, but this does effectively violate lexical scope boundaries as they > exist in the original source. If the yeas have it on SE-0159, and “private” is turned into “fileprivate”, the lexical scope boundaries

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution > wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford > wrote: > >> >> >> >> Sent from my iPhone >> On Mar 23, 2017, at 6:41 PM, David

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

I didn’t even know the compiler still supported these implicit conversions. So, +1, I guess. Charles > On Mar 23, 2017, at 12:35 AM, Robert Widmann via swift-evolution > wrote: > > Good evening all, > > Attached is the proposal text that came out of a short

[swift-evolution] Pitch: Partial Implementations

MOTIVATION: In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or struct’s declaration, particularly around protocols: class Foo { … } extension Foo: SomeProtocol { ... } extension Foo: SomeOtherProtocol { ... }

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution > wrote: > > I would argue that supporting whatever the programmer's chosen mental model > is actually Swift's greatest strength. We could have a language with only > reference types for example, it

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 24, 2017, at 12:09 PM, Douglas Gregor via swift-evolution > wrote: >> >> I'm actually not worried about methods so much as properties. KVC is >> completely untyped on the Objective-C side, and there are several different >> mechanisms there which use KVC

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 27, 2017, at 2:17 AM, Jonathan Hull wrote: > > Then you could keep it in the same file. As you said, the helper type is > tiny. > > (or once we have submodules, I suppose you could put it somewhere else in the > submodule, if desired) > > Thanks, > Jon But then the

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution > wrote: > > I'm considering this from a different angle. > > When we declare a type, we declare properties and functions which that type > has. > When we extend a type, we add functions to the type.

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 5:54 PM, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > > So with file-based `private`, there are only two reasons to care about which > file a piece of code is in—`private` access and subjective code > organization—and these two things are

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 26, 2017, at 11:57 AM, David Sweeris via swift-evolution > wrote: > > On Mar 26, 2017, at 08:50, David James via swift-evolution > > wrote: > >> • What is your evaluation of the proposal? >> -1 as

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 26, 2017, at 11:21 PM, Jonathan Hull via swift-evolution > wrote: > > I wonder if there is a different type of UI solution which might help people > who hate dividing things up into lots of small files. > > I find the way that I work is to make a super

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution > wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead

[swift-evolution] Pitch: @objc attribute for top-level functions

MOTIVATION: Sometimes, it’s necessary to write a top-level C function in order to interact with some C-based code. This can come up, for example, when making a new port for a cross-platform app that implements OS-dependent functionality via C functions. More urgently, though, it also pops up

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:15 PM, Matthew Johnson wrote: > > What I’m suggesting is that we could accomplish the same functionality by > enhancing extensions. You can make a case that using a different keyword for > same-module extensions that are allowed to have stored

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 1:21 PM, Matthew Johnson wrote: > > If we wanted to allow code like this to be written we wouldn’t need a new > keyword to do it. You are proposing two things here: > > 1) Allow stored properties in same-module extensions. This has been >

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 2:51 PM, Jean-Daniel via swift-evolution > wrote: > >> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution >> > a écrit : >> >> I agree that they can get mixed up with static

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution > wrote: > > Charles Srstka's added comment, while intriguing, poses a problem in > argumentation. One of the points being made above about the major advantage > of new `private` over `fileprivate` is

Re: [swift-evolution] Smart KeyPaths

Ah, yes, that would be annoying if editing .xib files caused SourceKitService dialogs to pop up every five seconds, the way editing .swift files does. Charles > On Mar 20, 2017, at 9:39 PM, Kenny Leung via swift-evolution > wrote: > > Wouldn’t this require the

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 4:15 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Mar 19

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> > wrote: >> >> >> >>> On 20 Mar 2017, at 10:39,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution > wrote: > > That’s why protected (a feature) is on the commonly rejected proposals list Unless you’re referring to a different “commonly rejected proposals” list than the one below, this does not appear

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution > wrote: > > So, if four/five access modifiers are too many, which one is carrying the > least weight? Which one could be removed to simplify the scheme while > maintaining the most expressiveness? Which

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 4, 2017, at 2:42 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > On Tue, Apr 4, 2017 at 3:30 PM, David Hart > wrote: > I agree with you. But that soft-default requires a simple and recognisable >

Re: [swift-evolution] (Pitch) Conformance Regions

Huge +1 in general, but with one exception: > On Mar 30, 2017, at 12:07 PM, Ross O'Brien via swift-evolution > wrote: > > struct Foo > { > conformance Bar // or conformance Foo : Bar, but since the region is inside > Foo that's redundant > { > var integer :

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1. This looks fantastic. Charles > On Apr 5, 2017, at 6:01 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > >

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1. This looks fantastic. Charles > On Apr 5, 2017, at 6:56 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for > Swift" begins now and runs through April 9, 2017.

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

I suggested that a while ago. Although I still think it’s the best solution (in addition to the benefits you mentioned, partials could also contain stored properties without making the behavior of extensions inconsistent), it didn’t seem to go over very well on the list, with people balking at

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution > wrote: > > I encountered this precise memory leak in my code a few days ago, so I > sympathize. A second solution would be to drop function references. I think a > core team member suggested it on

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 3:17 PM, Jaden Geller via swift-evolution > wrote: > > As I understood it, omitting the type would work identically to `let` > declarations. A string literal without a type defaults to `String`. Treating > it as a generic function is a bad idea

<    1   2   3   4   >