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

Comments inline. > On May 4, 2016, at 7:57 PM, Brent Royal-Gordon wrote: > They separate indentation from the string's contents. Traditional multiline > strings usually include all of the content between the start and end > delimiters, including leading whitespace. This means that it's usually

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution > wrote: > > In order for something like AnyValue to have meaning, we need to impose > greater order. After thinking through many approaches over the years, I > have arrived at the (admittedly rather drastic) opinion that the > lang

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution wrote: > -1 from me. We should not introduce two equivalent spellings for the same > thing. I agree with Jordan in this case. I’m aware of the ObjC precedent, but keep in mind that that precedent was formed in the pre-ANSI-C days. I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

Thanks Matthew. Personally I would really like to see an analysis of the tradeoffs therein covered in the proposal in some way. -Colin (via thumbs) > On May 4, 2016, at 8:23 PM, Matthew Johnson wrote: > > >>> On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution > wrote: > >> Swift numeric types all currently have a family of conversion initializers. >> In many use cases they leave a lot to be desired. Initializing an integer >> type with a floating point value will truncate any fraction

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

> Swift numeric types all currently have a family of conversion initializers. > In many use cases they leave a lot to be desired. Initializing an integer > type with a floating point value will truncate any fractional portion of the > number. Initializing with an out-of-range value traps. Have

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed May 04 2016, Matthew Johnson > wrote: > >>> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Wed May 04 2016, Adrian Zubarev wro

[swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md Hello Swift Community, The review of SE-0045: "Add scan, prefix(while:), drop(while:), and unfold to the stdlib" ran from April 28...May 3, 2016. A subset of the proposal is *accepted

[swift-evolution] [Accepted] SE-0017: Change Unmanaged to use UnsafePointer

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md Hello Swift Community, The review of SE-0017: "Change Unmanaged to use UnsafePointer" ran from April 28...May 3, 2016. The proposal is *accepted* for Swift 3. The feed

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Furthermore, YES/NO in Objective-C is not the same as true/false in Swift: I'm always watching out for code that checks if a BOOL value is YES, because YES just isn't the only true value in Objective C. The following code has a subtle bug in Objective-C whereas it works nicely in Swift. (One coul

[swift-evolution] [Accepted] SE-0032: Add find method to Sequence

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0032-sequencetype-find.md Hello Swift Community, The review of SE-0032: "Add find method to Sequence" ran from April 28...May 3, 2016. The proposal is *accepted* for Swift 3, with a requested naming revision: // Orig

[swift-evolution] [Accepted] SE-0052: Change IteratorType post-nil guarantee

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md Hello Swift Community, The review of SE-0052: "Change IteratorType post-nil guarantee" ran from April 28...May 3, 2016. The proposal is *accepted* for Swift 3. The feedback on this

[swift-evolution] [Accepted] SE-0069: Mutability and Foundation Value Types

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md Hello Swift Community, The review of SE-0069: "Mutability and Foundation Value Types” ran from April 25 ... May 4, 2016. The proposal is *accepted* for Swift 3. The feedback on

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, Matthew Johnson wrote: >> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed May 04 2016, Adrian Zubarev wrote: >> > >>> Not sure what to think about the enum cases inside a protocol (if AnyEnum >>> would >>> even exist), it could b

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

> On 4 May 2016, at 15:07, L. Mihalkovic wrote: > > Cool job!.. Yup, you proceed by "widening the existing holes" to carry the > missing info (eg Modifiers). Making direct changes to lexCharacter() is a > step I thought might be a bit premature considering nothing is carved in > stone yet. I

Re: [swift-evolution] [Pitch] Reference equivalent to value-type 'enum'

> On May 4, 2016, at 4:46 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution: > > Based on recent conversations on the list, I'd like to float a trial balloon: > an "enum class" kind which is analogous to classes in the same way existing > enums are to structs. This is a

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I’m a big fan of natural language style statements in code, but I think it would have to be a change of true/false or yes/no across the entire language, introducing lots of options creates uncertainty, especially for newer programmers. However I’m not sure if I’d want that, as true/false are the

[swift-evolution] [Pitch] Reference equivalent to value-type 'enum'

Hello swift-evolution: Based on recent conversations on the list, I'd like to float a trial balloon: an "enum class" kind which is analogous to classes in the same way existing enums are to structs. This is a data type which allows the user to define a number of cases, like enums, and can particip

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Agreed. -1. Sent from my iPhone > On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution > wrote: > > -1 from me. We should not introduce two equivalent spellings for the same > thing. > > (Yes, there are sometimes multiple ways to accomplish something, but they are > not nearly this

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 4:16 PM, David Sweeris wrote: > > Having given it some more thought... Does "PureReference" make sense? What > would it mean? At some point a reference has to, you know, actually refer to > a concrete value. Otherwise it's just turtles all the way down. In my thinking Pur

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 4:20 PM, David Sweeris wrote: > > ... And 30 seconds later I realized that "PureReference" could be fulfilled > by something with only static or computed properties. Any class that only had immutable value semantic members would fulfill PureReference. They would not need

Re: [swift-evolution] Introduce OrderedSet type

I think it would be nice to have a native Swift OrderedSet type, as well as a priority queue and support for collections holding weak references. This set of changes would go a long way towards providing Swift with a set of universally available, widely applicable data structures similar to those o

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

... And 30 seconds later I realized that "PureReference" could be fulfilled by something with only static or computed properties. Sent from my iPhone > On May 4, 2016, at 16:16, David Sweeris via swift-evolution > wrote: > > Having given it some more thought... Does "PureReference" make sens

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Having given it some more thought... Does "PureReference" make sense? What would it mean? At some point a reference has to, you know, actually refer to a concrete value. Otherwise it's just turtles all the way down. Sent from my iPhone > On May 4, 2016, at 13:32, Matthew Johnson wrote: > > >

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I agree - please - just don’t. This is easy enough to create on your own if you wish, but I think it is easier for new developers to the language not to have to ask what differences there are between ‘true’ and ‘yes’ and ‘YES' … etc On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution m

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

-1 from me. We should not introduce two equivalent spellings for the same thing. (Yes, there are sometimes multiple ways to accomplish something, but they are not nearly this close.) Jordan > On May 4, 2016, at 12:04, Erica Sadun via swift-evolution > wrote: > > I propose adding yes and no

Re: [swift-evolution] [Proposal] Tuple Extensions

If we wish to think more generally, would it then be necessary to, say, implement a finitary version of tuple extensions as an overload of the infinitary one? > On May 4, 2016, at 4:50 PM, Matthew Johnson wrote: > >> >> On May 4, 2016, at 3:46 PM, Robert Widmann via swift-evolution >> mailto

[swift-evolution] [Proposal] Tuple Extensions

Forwarding this reply to the list because I hit the wrong button. > Begin forwarded message: > > From: Robert Widmann > Subject: Re: [swift-evolution] [Proposal] Tuple Extensions > Date: May 4, 2016 at 4:45:21 PM EDT > To: Joe Groff > > Isn’t this assuming that tuples extensions would only com

[swift-evolution] [Pitch] merge types and protocols back together with type

This one have bothered me for days, since the idea came to my mind. I don't want to be too futuristic so here are my first thoughts. What if Swift 3 would have the ability to merge types and protocols together? Sure we will see generic typealias in Swift 3 but it doesn't allow us merge value ty

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I am a soft no on this if only because it seems unnecessary to augment such well-defined and meaningful constants to match Objective-C [e.g. we’re subject to the same set of “why does Swift use YES and NO when it already has true and false” questions that exist if you search around for “YES NO O

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 2:31 PM, Adrian Zubarev via swift-evolution > wrote: > > I kinda feel my idea went into the wrong direction. > > By introducing these implicit protocols (formatted with Source Code Pro font) > I didn’t meant them to force a type to have only reference or value semantics.

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I kinda feel my idea went into the wrong direction. By introducing these implicit protocols (formatted with Source Code Pro font) I didn’t meant them to force a type to have only reference or value semantics.                    +---+                    |  Any  |                    +---+---+

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

It's worth looking into CoffeeScript, in which true/false, yes/no, and on/off are all accepted. On Wed, May 4, 2016 at 12:04 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > I propose adding yes and no to the standard library as aliases for true > and false Boolean values.

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

Hi Rod, > On May 4, 2016, at 4:59 AM, Rod Brown wrote: > > > Tony, > > With regard to this proposal, is there any reason that this proposal did not > include an OrderedSet value type? I suspect perhaps this is an oversight? > > - Rod > We considered it, but did not include it in this propo

[swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I propose adding yes and no to the standard library as aliases for true and false Boolean values. When answering the questions posed by Boolean properties and methods, "yes" and "no" may provide better fits than "true" and "false". "Should this view be hidden?" "Yes!" "Does this collection cont

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

> On May 4, 2016, at 1:22 PM, Erica Sadun via swift-evolution > wrote: > > Here is a real world example of where I use defaulted parameters: > > public extension UIView { > public convenience init( > _ w: CGFloat, > _ h: CGFloat, > position: CGPoint = .zero, >

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed May 04 2016, Adrian Zubarev wrote: > >> Not sure what to think about the enum cases inside a protocol (if AnyEnum >> would >> even exist), it could be a nice addition to the language, but this is an own >>

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution > wrote: > > >> On May 4, 2016, at 11:12, Joe Groff via swift-evolution >> wrote: >> >> I can see value in there being some kind of PureValue protocol, for types >> that represent fully self-contained values, but conforming to

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On Apr 29, 2016, at 5:32 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md] > >

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 3, 2016, at 8:02 PM, Jordan Rose via swift-evolution > wrote: > > Dave and I have pondered this before, and considered that one possible > (drastic) solution is to ban classes from implementing protocols with > mutating members, on the grounds that it’s very hard to write an algorith

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Wed May 04 2016, Adrian Zubarev wrote: > Not sure what to think about the enum cases inside a protocol (if AnyEnum > would > even exist), it could be a nice addition to the language, but this is an own > proposal I guess. > > We should start by adding AnyValue protocol to which all value typ

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

Here is a real world example of where I use defaulted parameters:public extension UIView {    public convenience init(        _ w: CGFloat,        _ h: CGFloat,        position: CGPoint = .zero,        backgroundColor: UIColor = UIColor.whiteColor(),        translucency alpha: CGFloat = 1.0,       

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 11:12, Joe Groff via swift-evolution > wrote: > > I can see value in there being some kind of PureValue protocol, for types > that represent fully self-contained values, but conforming to that protocol > requires a bit more thought than just being a struct or enum, since

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

On Wed, May 4, 2016 at 2:24 AM, Gwendal Roué wrote: > >> Le 4 mai 2016 à 08:28, Pyry Jahkola via swift-evolution >> a écrit : >> >> Here's my review of "SE-0073: Marking closures as executing exactly once". >> >>> What is your evaluation of the proposal? >> >> +1. I think this is a good idea and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 4, 2016, at 10:15 AM, Jordan Rose wrote: > >> >> On May 4, 2016, at 10:07, Andrew Trick > > wrote: >> >>> >>> On May 4, 2016, at 9:40 AM, Jordan Rose >> > wrote: >>> On May 4, 2016, at 09:18, Joe Groff via swift-evolu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 4, 2016, at 10:15 AM, Jordan Rose wrote: > >> >> On May 4, 2016, at 10:07, Andrew Trick wrote: >> >>> >>> On May 4, 2016, at 9:40 AM, Jordan Rose wrote: >>> On May 4, 2016, at 09:18, Joe Groff via swift-evolution wrote: > > On May 3, 2016, at 9:39

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 4, 2016, at 10:07, Andrew Trick wrote: > >> >> On May 4, 2016, at 9:40 AM, Jordan Rose > > wrote: >> >>> >>> On May 4, 2016, at 09:18, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On May 3, 2016, at 9:39 PM

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

comments inline > Am 04.05.2016 um 05:52 schrieb Chris Lattner via swift-evolution > : > > Hello Swift community, > > The review of "SE-0060: Enforcing order of defaulted parameters" begins now > and runs through May 9. The proposal is available here: > > > https://github.com/apple/swi

[swift-evolution] [Review] SE-0082: Package Manager Editable Packages

Hello Swift community, A review of "Package Manager Editable Packages" for the Swift Package Manager begins now and runs through Saturday, May 7th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md Reviews are a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 4, 2016, at 9:40 AM, Jordan Rose wrote: > >> >> On May 4, 2016, at 09:18, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 4, 2016, at 09:18, Joe Groff via swift-evolution > wrote: > >> >> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution >> wrote: >> >> >>> On May 3, 2016, at 8:56 PM, Chris Lattner wrote: >>> >>> Hello Swift community, >>> >>> The review of "SE-0076: Add overrides takin

Re: [swift-evolution] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> * What is your evaluation of the proposal? It makes sense to have `assignFrom` and `initializeFrom` defined for `UnsafePointer` sources. I would much rather see them defined simply with `UnsafePointer` rather than having overloads. The ability to use UnsafeMutablePointer with UnsafePointer p

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

I wonder if there is a practical use-case for this.. Is there? Just curious... -Michael > Am 03.05.2016 um 17:07 schrieb Marc Prud'hommeaux via swift-evolution > : > > > The following code currently has a retain cycle and memory leak: > > enum ParentChild { > case SonOf(Parent) > case

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 3, 2016, at 9:39 PM, Andrew Trick via swift-evolution > wrote: > > >> On May 3, 2016, at 8:56 PM, Chris Lattner wrote: >> >> Hello Swift community, >> >> The review of "SE-0076: Add overrides taking an UnsafePointer source to >> non-destructive copying methods on UnsafeMutablePoin

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

This is clever, but I’m not sure it’d get used anywhere else. In particular, I don’t think we want to demote the Apple OSs to be “Apple.OSX” and “Apple.iOS”, even though asking “am I on an Apple platform” is a reasonable question. Similarly, “POSIX?” is a reasonable query to ask of most OSs, but

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution > wrote: > > Something about your first paragraph reminded me of a question I've had for a > while. Is there a reasoning behind not being able to restrict a protocol to > value types? One way that this might be workable is if we co

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

Hi, just a quick question... would it maybe be feasible or practical to have "sub-OSes", like e.g. `#if os(Windows.MSVC)`, `#if os(Windows.Cygwin)` or `#if os(Windows.MinGW)`? -Michael > Am 03.05.2016 um 20:43 schrieb Jordan Rose via swift-evolution > : > > We’ve had this kind of thing come

Re: [swift-evolution] [Proposal] Tuple Extensions

> On May 3, 2016, at 10:06 PM, Robert Widmann wrote: > > Once-and-for-all implementations come in many flavors. For now, we have > clear interest in making a limited subset of possible tuples properly > Comparable. This will also make it easier to implement extensions to > specific arities

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

First, a general +1 to these, thanks for proposing them. In SE-0067 we spelled these “exactly” rather than “exact”. init?(exactly value: Source) As for –0, Int(exactly: -0.0) should *not* fail. My rationale for this is as follows: - While information (the signbit) is lost, the essential proper

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 3, 2016, at 11:26 PM, Gwendal Roué via swift-evolution > wrote: > >> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now >> and runs through May 9. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0

Re: [swift-evolution] [Pitch] Richer function identifiers, simpler function types

Sorry for answering this late, but I think this is a great proposal and would like to see especially the `foo(_)` syntax up for review, as it came up twice already while Doug Gregor and I discussed the implementation of getters and setters for #selector (here

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 3, 2016, at 11:19 PM, Charles Srstka via swift-evolution > wrote: > > Is the proposal to add these initializers to protocols like IntegerType, or > just to individually add them to each of the numeric types? It’s unclear from > the proposal, but in case that question hasn’t been deci

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

> * What is your evaluation of the proposal? I am unsure. I am definitely not fully convinced yet. I believe a change like this deserves more analysis of the impact of reordering on call site clarity when used with existing APIs. If the argument labels of defaulted parameters in most

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

> On May 4, 2016, at 1:51 PM, John Holdsworth wrote: > > … response inline > >>> On May 2, 2016, at 2:23 PM, John Holdsworth wrote: >>> >>> I'm having trouble getting the `e` modifier to work as advertised, at least for the sequence `\\`. For example, `print(e"")` prints two

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> * What is your evaluation of the proposal? I support the idea, since binary search is obviously a very important algorithm which would be important to have in the standard library. I am, however, unsure about the implementation. The current proposal suggests to add the new methods to the Collec

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

** ** On May 4 2016, at 5:37 pm, James Froggatt wrote: > I was thinking that requiring instance properties would mean the value could only be a struct, but rethinking, I realise computed properties would work fine for protocol conformance, so this isn't actually

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Your comment on overloads for reference types gave me an idea. I've just tried in a playground, and overloading is currently possible for protocol extensions. Providing an implementation, then separate ones in an extension where Self: AnyObject, will cause the compiler to choose the more specifi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

>* What is your evaluation of the proposal? +1. I'm pleased to see an important foundational algorithm added to the standard library. >* Is the problem being addressed significant enough to warrant a change to > Swift? Yes. We should have a standard, shared implementation of as many

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

> * What is your evaluation of the proposal? -1. The proposed change seems to require a somewhat complex implementation in the compiler, and I fail to see clear benefits in the change. > * Is the problem being addressed significant enough to warrant a change to Swift? Frankly, I don't think the

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Sent from my iPad > On May 4, 2016, at 7:28 AM, T.J. Usiyan via swift-evolution > wrote: > > Something about your first paragraph reminded me of a question I've had for a > while. Is there a reasoning behind not being able to restrict a protocol to > value types? One way that this might be

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Something about your first paragraph reminded me of a question I've had for a while. Is there a reasoning behind not being able to restrict a protocol to value types? One way that this might be workable is if we could overload protocols for Value vs for reference. TJ On Tue, May 3, 2016 at 11:02

[swift-evolution] Property observers in protocol extensions

There should be property observers in protocol extensions, so that even property observers will get default implementations, like functions or computed properties. Andru ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

Tony, With regard to this proposal, is there any reason that this proposal did not include an OrderedSet value type? I suspect perhaps this is an oversight? - Rod > On 4 May 2016, at 1:50 PM, Rod Brown via swift-evolution > wrote: > > I believe this would fall in line with by Proposal SE-00

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

… response inline > On May 2, 2016, at 2:23 PM, John Holdsworth > wrote: > >> >>> I'm having trouble getting the `e` modifier to work as advertised, at least >>> for the sequence `\\`. For example, `print(e"")` prints two >>> backslashes, and `print(e"\\\")

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Not sure what to think about the enum cases inside a protocol (if AnyEnum would even exist), it could be a nice addition to the language, but this is an own proposal I guess. We should start by adding AnyValue protocol to which all value types conforms. The reason I introduced AnyReference is

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Hi Gwendal, Nice writeup. So I see that you recognise how this extra specification will complicate (while also facilitate) things. And I also see that you're a co-author of the proposal. So I'm more than happy if you can squeeze this extra into it. However reading your example code, I had to s

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

> Le 4 mai 2016 à 08:28, Pyry Jahkola via swift-evolution > a écrit : > > Here's my review of "SE-0073: Marking closures as executing exactly once". > >> What is your evaluation of the proposal? > > +1. I think this is a good idea and should be accepted (without extending the > proposed scop

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Thanks. It's a shame this isn't being addressed. I find myself always considering whether things are value-type or reference-type when writing generic code, avoiding assignments to self for this reason, and feel bad adding mutating methods to protocols knowing that it will make the protocol almo

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I was thinking that requiring instance properties would mean the value could only be a struct, but rethinking, I realise computed properties would work fine for protocol conformance, so this isn't actually true. I agree with your support of focusing on interface. Your implications for AnyObject

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

>* What is your evaluation of the proposal? I like the proposal and I think it's a good idea, but I'm really not sure it is important enough to fix. Looking at the proposals already accepted, half of them are still waiting for an implementation. Several will probably never make it in time