[swift-evolution] Ability to mark a class as publicly final while remaining internally non-final

Consider a public class that conforms to an internal protocol that has an initializer requirement: internal class SomeInternalClass { } internal protocol SomeInternalProtocol { init(parameter: SomeInternalClass) } public class SomePublicClass: SomeInternalProtocol { // compiler error: initi

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

+1 I've been missing this myself -Thorsten > Am 25.04.2016 um 04:15 schrieb Rod Brown via swift-evolution > : > > I'm definitely a supporter of this change. It addresses things I've hit > multiple times. > >> On 25 Apr 2016, at 6:34 AM, David Hart via swift-evolution >> wrote: >> >> I wro

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

I think there are some good points here. As a riff, though, I'd argue that Obj-C optional should *not* be renamed to elective or something else. Renaming, so far, has been for the purpose of providing first-class Swifty idioms for existing things. It makes moving between Swift-native code and legac

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

> On Apr 24, 2016, at 7:57 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md > > I'm not totally clear what's being proposed here. > > Is this valid? > > class Foo { > st

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I'm definitely a supporter of this change. It addresses things I've hit multiple times. > On 25 Apr 2016, at 6:34 AM, David Hart via swift-evolution > wrote: > > I wrote the proposal which was discussed to introduce generic constraints for > associated types. I’d like to get some feedback on

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

Sent from my iPhone > On Apr 24, 2016, at 3:24 PM, Xiaodi Wu wrote: > >> On Sun, Apr 24, 2016 at 4:28 PM, Chris Lattner wrote: >> >> > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution >> > wrote: >> > >> > >> > >> > Sent from my iPhone >> > >> >> On Apr 22, 2016, at 5:56 PM,

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution >> wrote: >> >> >> >> Sent from my iPhone >> >>> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: >>> >>> Not an expert on Obj-C compatibility i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

> > https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md I'm not totally clear what's being proposed here. Is this valid? class Foo { static func bar() { … } func baz(other: Foo) { Self.bar()

Re: [swift-evolution] [Idea] Repurpose Void

> Some people, including me, argue that Void should be removed altogether, > because: > 1) () is more consistent with curried functions: (Int) -> () -> Double > 2) () follows functional programming traditions > > Now, why don't we repurpose Void to follow functional programming traditions > as w

Re: [swift-evolution] multi-line string literals.

To audition Xcode using the following multi-line syntax: let xml = " " " " \(author) " XML Developer's Guide " Computer " 44.95 " 2000-10-01 " An in-depth

Re: [swift-evolution] Mutability for Foundation types in Swift

The proposal looks great. ## Introduction Broken link: -- ++ ### New Value T

Re: [swift-evolution] Rewrite imported C function signatures

Thanks for the explanation, which makes me think that it should be suitable, as you comment, to promote API notes to a “first class” transition technology. As a first approach towards that goal, would it be ok to expand the notion of “bridging headers” to also include API notes? In that case, it

Re: [swift-evolution] multi-line string literals.

> On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution > wrote: >> I’m trying to avoid more advanced features such as the handling of indenting >> which >> for me complicates something that if kept simple can be documented very >> easily. > > I don't think you can tackle multil

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Sun, Apr 24, 2016 at 4:28 PM, Chris Lattner wrote: > > > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > > Sent from my iPhone > > > >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: > >> > >> Not an expert on Obj-C compatibil

Re: [swift-evolution] multi-line string literals.

On Apr 22, 2016, at 12:54 PM, Patrick Gili via swift-evolution wrote: > If we use a quoting structure similar to Perl6, then we future proof the > grammar to accommodate regular expression literals (and multi-line regular > expression literals) later. It also gives us the possibility for suppor

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 4:51 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > However, I don’t understand how that would help for floating point NaN > behavior. Wouldn’t you have to add a fourth member to the enum > (“unordered’) that all clients would have to ha

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 22, 2016, at 4:05 PM, Vladimir.S wrote: > > After some discussions, I support this proposal and think this will make > Swift more consistent and clear about where is parameters and where is result > type. Especially this important in code like: > Int -> String -> Void -> Float > which

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> On Apr 24, 2016, at 2:51 PM, Brent Royal-Gordon wrote: > >> However, I don’t understand how that would help for floating point NaN >> behavior. Wouldn’t you have to add a fourth member to the enum >> (“unordered’) that all clients would have to handle? An approach like that >> could make

Re: [swift-evolution] Guaranteed closure execution

> On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution > wrote: > > Hello Andrew, > > I'm rather embarrassed: the initial design of this proposal was based on a > modifier of @noescape: > > func f(@noescape(once) closure: () -> ()) { … } > > But since the 0049 proposal has be

Re: [swift-evolution] multi-line string literals.

This isn’t the best argument but they can be very slow to compile :( > On 24 Apr 2016, at 22:52, Ted F.A. van Gaalen wrote: > > let purpleRain =// in remembrance to one of my favorite artists. > “What’s wrong with concatenating string constants with “ + > “plus-signs, like in this exam

Re: [swift-evolution] multi-line string literals.

let purpleRain =// in remembrance to one of my favorite artists. “What’s wrong with concatenating string constants with “ + “plus-signs, like in this example? \n\n“+ “I am quite happy with doing it this way. ” + “No problem, kind regards

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

On Apr 20, 2016, at 10:18 PM, David Owens II wrote: >>> Obviously, given a name to the parameter brings clarity and can be self >>> documenting, but if we want the above to work while making names just as >>> vital as the type signature, then we need to declare `Functor` as such: >>> >>> typeal

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> However, I don’t understand how that would help for floating point NaN > behavior. Wouldn’t you have to add a fourth member to the enum (“unordered’) > that all clients would have to handle? An approach like that could make > sense. The point is precisely that there *isn't* an `unordered` c

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

On Apr 21, 2016, at 3:12 PM, Chris Willmore via swift-evolution wrote: > I evaluated the effects of this proposal on five projects written in Swift > against Foundation and other well-audited OS X and iOS Objective-C APIs. The > only changes that had to be made were the result of Objective-C AP

Re: [swift-evolution] Localization support for string interpolation

> On Apr 24, 2016, at 2:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution >> wrote: >> >> Hi there! >> >> TL;DR: Here’s my idea for a better localized strings handling in Swift. >> It includes both, support for string in

Re: [swift-evolution] Carriage Return in Collection Array Literal Initializer

There was a discussion some time ago about making the comma of the last entry optional, because adding entries meant changing more than one line of code and this annoyed users of version control systems. This is an elegant approach to that problem. I don't know if it's a practical approach for the

Re: [swift-evolution] Localization support for string interpolation

> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution > wrote: > > Hi there! > > TL;DR: Here’s my idea for a better localized strings handling in Swift. > It includes both, support for string interpolation support for > NSLocalizedString, and a new string delimiter `...` that can be

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: >> >> Not an expert on Obj-C compatibility in Swift by any means, but this >> reads like it's largely a change of nomenclature. To me, t

[swift-evolution] Carriage Return in Collection Array Literal Initializer

Sometimes in is necessary to initialize a collection with a long list of items. Consider this example: let dictionaryWithALotOfItems = ["someString0" : SomeFunctionality.0, "someString1" : SomeFunctionality.0, "someString2" : SomeFunctionality.0, "someString3" : SomeFunctionality.1, "someString

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

On Apr 23, 2016, at 6:01 AM, Haravikk via swift-evolution wrote: > While I know it might be a bit strange to have different rules for each side, > I think I prefer empty brackets on the left and Void on the right, but in > combination with required parenthesis on the left. FWIW, it *does* make

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Apr 23, 2016, at 6:28 PM, Brent Royal-Gordon via swift-evolution wrote: > Simple and straightforward, but not actually accurate. In a strict total > order, all elements are ordered, but that's not true of the current > Comparable. For instance, floating-point NaNs are not ordered. > In short

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> Regarding how this affects sorting methods though, some people (myself > included) like the simplicity of being able to do the following: > > myArray.sort(>) // If array is of Comparable elements, just throw in > the operator That is extremely convenient. With my proposed extensions, it

[swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I wrote the proposal which was discussed to introduce generic constraints for associated types. I’d like to get some feedback on it and get it ready before submitting it: More Powerful Constraints for Associated Types Proposal: SE-

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

> On 24 Apr 2016, at 17:41, Xiaodi Wu wrote: > > Regarding how this affects sorting methods though, some people (myself > included) like the simplicity of being able to do the following: > > myArray.sort(>) // If array is of Comparable elements, just throw in > the operator > > While f

Re: [swift-evolution] Guaranteed closure execution

> Le 23 avr. 2016 à 18:33, Timothy Wood a écrit : > > > >> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution >> > [...] >> >> Since @once actually implies @noescape (as described earlier in the thread), >> it can be shortened to: > [...] > > I'm surprised that @once would imply

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 5:28 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > Is there a reason that NaN can’t just compare in a more useful way, e.g- > always return true for the less than operator unless the other value is > also NaN, thus ensuring it always comes first in

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > > The idea of distinguishing all mutating/non-mutating functions with only > the assignment operator did occur to me as I wrote that. > > Using such a rule would allow automatic generation of

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The idea of distinguishing all mutating/non-mutating functions with only the > assignment operator did occur to me as I wrote that. > Using such a rule would allow automatic generation of mutating methods from > non-mutating ones, since the naming would no longer need changing. > However, this

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

The idea of distinguishing all mutating/non-mutating functions with only the assignment operator did occur to me as I wrote that. Using such a rule would allow automatic generation of mutating methods from non-mutating ones, since the naming would no longer need changing. However, this would also

Re: [swift-evolution] Properties with parameters

> Tim Vermeulen via swift-evolutionwrites: > > > Properties are great. They allow us to write the more naturally looking > > > > myButton.hidden = true > > > > instead of > > > > myButton.setHidden(true) > > > > However, they don't take any parameters. That’s why we still have to write > > >

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> The whole naming issue seems to be caused by the .union(_:) function. The > Swift Guidelines say that mutating functions should use a verb, and > non-mutating forms should use a noun, but in this case, the word union itself > is a verb and a noun. > > Have we considered this, then: > > a.uni

Re: [swift-evolution] multi-line string literals.

It’s +1 from me also. Swift’s Lexer is less than 2000 lines in it’s entirety whereas Perl’s tokeniser is more than 11,000 lines so I don’t think this is a direction we want to head in. Besides, I don’t feel there is a need for more than one type of string as Swift's \() interpolation syntax is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 4/23/16 21:53, Brent Royal-Gordon via swift-evolution wrote: >> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible { >> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible { > > Any reason why FloatLiteralConvertible isn't on FloatingPoint? While I'm n

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Yes +1 I think how the compiler can’t work with two methods with the same name, where one has a result, and other mutating, needs to be fixed to enable nice APIs. Patrick On Sun, Apr 24, 2016 at 2:33 AM -0700, "James Froggatt via swift-evolution" wrote: The whole naming issue see

Re: [swift-evolution] Mutability for Foundation types in Swift

> We took this feedback seriously, and I would like to share with you the start > of an important journey for some of the most commonly used APIs on all of our > platforms: adopting value semantics for key Foundation types. This proposal is way cool, and I think you've selected a great starting

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

Is there a reason that NaN can’t just compare in a more useful way, e.g- always return true for the less than operator unless the other value is also NaN, thus ensuring it always comes first in ascending order? Or is there too much of a performance cost to make it a special case? That said I’m

[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> > func isEqual(to other: Self) ->Bool > > func isLess(than other: Self) ->Bool > > func isLessThanOrEqual(to other: Self) ->Bool > > I'm still not sure why these are methods instead of operators. I think this is an *excellent* choice, and I hope it is the first step to completely removing opera

Re: [swift-evolution] [Proposal] Safer half-open range operator

Many thanks, Vladimir, I wasn't familiar with this yet. :-) - Luis On Sun, Apr 24, 2016 at 7:10 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > We already have this feature(to append labels for substiption), so I > believe it is possible to implement this proposal: > > c

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun. Have we considered this, then: a.union(b) //mutating