Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 25, 2017, at 6:07 PM, Daniel Duan via swift-evolution > wrote: > > Not sure which “this” you were referring to. The anonymous case part is > something that I consider out-of-scope for this proposal as well. It came up > during review and is posted as one of the core team’s request. T

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 2:54 PM, Michael Ilseman wrote: > > >> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Ted, >> >> It might have helped if instead of being called String and Character, they >> were named Text > > I would

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Not sure which “this” you were referring to. The anonymous case part is something that I consider out-of-scope for this proposal as well. It came up during review and is posted as one of the core team’s request. There are two possibilities regarding this feature: I can put it in future considera

Re: [swift-evolution] [Draft] Package Manager Manifest API Redesign

Was looking forward to this :) here are my comments: > On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution > wrote: > > Hi all, > > Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for a > Package.swift manifest API redesign for the Package Manager. We'll welcome >

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:23 PM, Jonathan Hull wrote: > > >> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:01 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 1:19 PM, Matthew Johnson > > wrote: >>> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> +1000 >>> >>> This is the bes

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> … >>> Additionally, the design allows ‘final’ to take any one of those visibility >>> level

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 1:19 PM, Matthew Johnson wrote: >> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> +1000 >> >> This is the best of the proposals I have seen. I think it works by itself >> as a complete proposal, but since we

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution > wrote: > > Ted, > > It might have helped if instead of being called String and Character, they > were named Text I would oppose taking a good name like “Text” and using it for Strings which are mostly for machine processing p

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution > wrote: > > I don't have a good answer for this, but I'll vote against 'foo(:)' because > that's what a lot of people think the name of 'foo(_:)' should be. I'd rather > be able to offer fix-its for that even when you have both 'foo

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution > wrote: > >> … >> Additionally, the design allows ‘final’ to take any one of those visibility >> levels as a parameter, to indicate that the type should be treated as >> ‘final’ at and above the specified scope. Thus ‘final(p

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> … > Additionally, the design allows ‘final’ to take any one of those visibility > levels as a parameter, to indicate that the type should be treated as ‘final’ > at and above the specified scope. Thus ‘final(public)’ prevents subclassing > outside the module, while ‘final(internal)’ prevents i

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution > wrote: > > +1000 > > This is the best of the proposals I have seen. I think it works by itself as > a complete proposal, but since we are talking "comprehensive rethink", there > is one use case which mos

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

+1000 This is the best of the proposals I have seen. I think it works by itself as a complete proposal, but since we are talking "comprehensive rethink", there is one use case which most of the proposals seem to miss. That is, what if I want to make a class which is both Public and Subclassa

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> I think everybody agrees (at the very least to some degree) that the current > access level system is too complicated. I'm not sure about that — discussions about adding even more access levels aren't that uncommon, and peoples opinions tend to be surprisingly diverse. I guess that the rate of

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Maybe I'm missing something obvious (or maybe I'm just generally in favour for case classes ;-), but as the main motivation for the proposal seems to be that enum cases should be more function-like: Why is this desirable? ___ swift-evolution mailing lis

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 25, 2017, at 6:13 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Before I start revising this proposal, there are a couple of open questions >> I’d like to disc

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

I’m back to writing Objective-C again, and it is actually warning you about possible reference cycles in your closures. I’m for Swift doing the same. -Kenny > On Feb 20, 2017, at 3:22 AM, Lauri Lehmijoki via swift-evolution > wrote: > > I'm developing an application where we use RxSwift heavi

Re: [swift-evolution] [Manifesto] Ownership

1: Collection Composition As much as the high-level picture is focused on safety, I’d just like to request a strong focus on making sure the eventual ownership system addresses the common issues like avoiding copies when mutating through optionals, or when nesting collections, and so on. Point

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

I assume that Number being renamed Numeric implies SignedNumber being renamed SignedNumeric? On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > < > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md > > > > >

Re: [swift-evolution] Sequence/Collection Enhancements

Some belated feedback. > On Feb 16, 2017, at 6:39 PM, Ben Cohen via swift-evolution > wrote: > Here is a list of commonly requested algorithms to operate on Sequence or > Collection: > > In-place transformations: > transform elements in a MutableCollection using a closure i.e. in-place map +0.

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 24 Feb 2017, at 02:05, Ben Cohen wrote: > > Regarding the “Number” protocol: it was felt this is likely to cause > confusion with NSNumber, given the NS-prefix-dropping versions of other > Foundation

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 12:12 AM, David Waite via swift-evolution > wrote: > >>> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution >>> wrote: >> > >> >> The prevailing view from recent discussions is that there should be just one >> access level mo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Sent from my iPad > On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution > wrote: > > Before I start revising this proposal, there are a couple of open questions > I’d like to discuss with the community and the core team. > > The first question relates to the purpose of having a “i

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 25 Feb 2017, at 01:25, Robert Bennett via swift-evolution > wrote: > >> Sorry, that turned into a bit of a rant, though hopefully a constructive >> one. I wasn't directing this at you in particular; I just wanted to properly >> get those points across. > > No worries at all, we're all w

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 24 Feb 2017, at 02:05, Ben Cohen via swift-evolution > wrote: > > Regarding the question of the trailing argument to distinguish > overflow-checking vs expanding versions of multiplied: rather than add an > enum or use the void trick in order to do this via arguments, it is better to >

Re: [swift-evolution] Analysis of existing scopes

> Le 25 févr. 2017 à 02:55, Xiaodi Wu a écrit : > > It is a useful generalization of an absolutely obligatory feature for new > `private`. Consider the following: > > ``` > private class Foo { > private class Bar { > /* blank */ class Baz { } > } > } > ``` > > What access modifier can

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

I have to admit I don’t get why there’s so much push back about the whole public/open debate. I understand that completely removing the possibility to declare internally subclassable but publicly closed classes (like it did) might be harmful, but I’m still convinced that this use-case isn’t wort