Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Drew Crawford via swift-evolution
I agree with all of this, and I lack strong feelings about whether this should be restricted to the same compilation unit or allowed in multiple compilation units. On March 23, 2017 at 1:12:51 PM, Charles Srstka via swift-evolution (swift-evolution@swift.org) wrote: MOTIVATION: In current Swi

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Haravikk via swift-evolution
> On 24 Mar 2017, at 12:13, Vladimir.S wrote: >> On 24.03.2017 12:50, Haravikk wrote: >> I can see why some people might want to do stored properties in extensions >> to structure things, but personally I quite like the lack of flexibility as >> it encourages the initial type declaration to focus

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Vladimir.S via swift-evolution
On 24.03.2017 14:09, Pranshu Goyal wrote: I agree with Haravikk, enabling stored properties in extension will lead to abuse of the feature, and people will start putting any and everything while modeling classes retroactively, rather than think about the real meaning and purpose of extensions whi

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Vladimir.S via swift-evolution
On 24.03.2017 12:50, Haravikk wrote: On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution mailto:swift-evolution@swif

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Pranshu Goyal via swift-evolution
Hello Karl, Don't you think stored properties in extensions would encourage the kind of code you talked about. I believe may you're doing it while understanding it's implications and also accepting the fact that it's not easy to write UI code in a modular way, but do we want everyone to think like

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Karl Wagner via swift-evolution
> On 24 Mar 2017, at 10:50, Haravikk via swift-evolution > wrote: > >> >> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: >>> On Mar 23, 2017, at 1:12 PM, Charles

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Pranshu Goyal via swift-evolution
I agree with Haravikk, enabling stored properties in extension will lead to abuse of the feature, and people will start putting any and everything while modeling classes retroactively, rather than think about the real meaning and purpose of extensions which is to provide extended functionality or c

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-24 Thread Haravikk via swift-evolution
> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution > wrote: > > On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: >> >>> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution >>> wrote: >>> >>> MOTIVATION: >>> >>> In current Swift, a pattern has emerged among

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Karl Wagner via swift-evolution
> On 23 Mar 2017, at 21:36, Slava Pestov via swift-evolution > wrote: > > >> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> 1) Allow stored properties in same-module extensions. This has been >> discussed in the past and

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Vladimir.S via swift-evolution
On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution wrote: 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

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Slava Pestov via swift-evolution
> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution > wrote: > > 1) Allow stored properties in same-module extensions. This has been > discussed in the past and is a possibility, but I suspect it is not in scope > for consideration during Swift 4. Allowing stored properties

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Jonathan Hull via swift-evolution
-1 I would much rather see the ability to introduce stored properties in extensions (within the module) + simple file-based submodules. Also, I think you are missing important parts of the extensions + fileprivate pattern. Sure, a big part of it is being able to group conformances together in

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Matthew Johnson via swift-evolution
Sent from my iPhone > On Mar 23, 2017, at 2:47 PM, Charles Srstka wrote: > >> 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

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Charles Srstka via swift-evolution
> 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 of *everything* will be vi

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Matthew Johnson via swift-evolution
> On Mar 23, 2017, at 2:37 PM, Charles Srstka wrote: > >> 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

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Charles Srstka via swift-evolution
> 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 properties is a good > id

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Matthew Johnson via swift-evolution
> On Mar 23, 2017, at 2:04 PM, Charles Srstka wrote: > >> 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) Al

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Charles Srstka via swift-evolution
> 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 > discussed in the past and is a

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Rien via swift-evolution
I think the access levels should be revised, no need to introduce a new concept. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 23 Mar 2017, at 19:12, Charles Srstka via swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Matthew Johnson via swift-evolution
> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution > wrote: > > 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 { > … >

[swift-evolution] Pitch: Partial Implementations

2017-03-23 Thread Charles Srstka via swift-evolution
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 { ... }