Re: [swift-evolution] Partial list of open Swift 3 design topics

> - Bridge NSRange to “Range?” I don’t think I can handle writing a proposal for this one, but I’d die for it. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I did not pay a lot of attention to this renaming because I thought the trailing closure syntax would shield me from labels. But I forgot that in if/for/while statements, I’m going to be forced to use them. In those cases, I’d prefer more succinct labels. I added some comments inline where I ha

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: > >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote: >> That's a really interesting idea. Is "Syntax" a placeholder, or is that the >> intended name? > > It is the best name we could come up with, we are open to better suggestions. I

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

Do we lose the ability to create a signed integer from an unsigned bit pattern? Is there a way to get an optional initializer that returns `nil` if the operand can't be represented? What is the cost of heterogeneous comparison? Félix > Le 22 juin 2016 à 22:42:00, David Waite via swift-evolutio

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

Please see https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/Null.swift https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/JSON.swift <

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

> On Jun 22, 2016, at 10:14 PM, Alsey Miller via swift-evolution > wrote: > > Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null > is more performant (no ARC or memory allocation) than NSNull, and will be > needed for Swift JSON decoders and libraries that want to us

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

In addition to the technical review, I would like to point out that the definition of Arithmetic appears to be missing some underscores in add/adding/subtract/subtracting > > > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md > > * What is yo

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

> * What is your evaluation of the proposal? -1. It removes a feature that I love about Swift. When `for;;;` was removed, I thought to my self , we have `where` to help on tricky situations. Removing `where` would make working with for loops more terse. I do not like using guards in my for

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

There’s a great discussion going on here, and I don’t mean to distract. But I want to ask: to get an infinite sequence using the Swift standard library, you’re going to have to create one yourself, say using the new `sequence()` functions? There’s nothing built in that is already infinite, so pe

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 7:12 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jun 22, 2016, at 6:41 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson > > wrote: >>

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 7:42 PM, Matthew Johnson wrote: > > On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > > On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > wrote: > > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-c

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

Yes, I’m all for removing this syntax which seems to confuse people with what it actually does. Having to write more explicit code with a `guard` or `.filter` is better than people unexpectedly creating bugs. I’d say remove it for Swift 3, allowing a potential replacement for this functionality

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0077: Improved operator declarations

> On Jun 22, 2016, at 8:24 PM, Joe Groff wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > > > Hello Swift Community, > > The

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 2:57 PM, Dave Abrahams via swift-evolution > wrote: > > “Iterators,” please. That makes me happy - for some reason I thought it was still GeneratorProtocol >> destructively, but such Generators would not conform to the needs of >> Sequence. As such, the most significant

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

This kind of sounds like the proposal to have implicit return in guard statements. I agree with John that this kind of feels incosistent and obscure. An alternative that could be used everywhere though may look like this: func myFunc() -> String { autoreturn { return "He

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

> * What is your evaluation of the proposal? -1. As I was all along during the discussion here, I find the ability to automatically filter the sequence using where as useful and a nice language feature. I do not find the syntax confusing, on the other hand the alternatively suggested repl

[swift-evolution] [Pitch] Add Null struct to Foundation

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is more performant (no ARC or memory allocation) than NSNull, and will be needed for Swift JSON decoders and libraries that want to use struct value types, and be free from classes for their model layer. Colem

[swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

Hello Swift community, The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now and runs through June 29. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md Reviews are an important pa

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

> On Jun 22, 2016, at 7:59 PM, Jordan Rose via swift-evolution > wrote: > >>> >>> I would really like to see submodules, but I think there would still be >>> valid uses for `fileprivate` even with them. But of course we would need >>> to know the details of submodules to have a good discuss

[swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md Hello Swift Community, The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to return the first version of this proposal fo

[swift-evolution] [Accepted] SE-0089: Renaming String.init(_: T)

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Hello Swift Community, The second review of SE-0089: "Renaming String.init(_: T)" ran from June 4...7. The proposal is *accepted* for Swift 3. The feedback from the community o

Re: [swift-evolution] Partial list of open Swift 3 design topics

> - Bool is a simple enough concept to not need a family of protocols. Literally, the most fundamental concept. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Partial list of open Swift 3 design topics

On Jun 22, 2016, at 6:16 PM, Xiaodi Wu wrote: > - Remove Boolean protocol. > ^^^ > What's the thinking behind this particular item? > “Boolean” isn’t pulling its weight: - It only abstracts over Bool and ObjCBool. - It only enables a few operations on ObjCBool, which are not very important. -

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > > On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md >> >> Re

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

You’re right on the specifics, of course. To be clear I am more concerned about accidental shadowing with such subscripts; picture starting initial development with only the generic subscript from the proposal, writing some code that uses it…and then at some later point in time importing a modu

Re: [swift-evolution] [Review] SE-0095: Replace `protocol` syntax with `Any`

On Wed, Jun 22, 2016 at 2:04 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0095: Replace `protocol` syntax with > `Any`" begins now and runs through June 27. The proposal is > available here: > > > https://github.com/apple/

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Let's not go through more churn with `pointee`. It's already just been changed from `memory`. On Wed, Jun 22, 2016 at 21:02 Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >

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

Sent from my iPhone > On Jun 22, 2016, at 9:32 PM, Karl via swift-evolution > wrote: > > I would like ‘floor’ and ‘ceil’ to be part of the standard library (or some > equivalent). It annoys me that I have to import Darwin/Glibc to properly > convert between standard library types. Would thi

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution wrote: > > > Hi All, > > A couple of weeks ago we started to notice that we had some poorly-named > closure parameters and argument labels in the standard library, so we > did a complete audit of the standard library's APIs and cam

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

> * What is your evaluation of the proposal? This looks really great! Thank you team for all of your hard work on improving the numeric protocols in Swift 3. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. The current protocols leave a

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

Karl - Absolute value of `Int.min` is currently not representable by an Int. On Wed, Jun 22, 2016 at 9:32 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Looks very good. A couple of points: > > - I’m not convinced about ‘absoluteValue’, with an associated type. I > thin

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

+1 Looks very good. A couple of points: - I’m not convinced about ‘absoluteValue’, with an associated type. I think it should return the same value as ‘abs()’ or have a different name if it’s really needed at all; the example of a print function is a bit weak IMO. - I’m not sure about an ‘nthWo

Re: [swift-evolution] Partial list of open Swift 3 design topics

I'd be happy to put together proposals for associated type inference removal and removing type system significance from argument labels, if nobody else wants them. Austin On Wed, Jun 22, 2016 at 6:16 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > > > On Wed, Jun 22, 2016

Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Wed, Jun 22, 2016 at 8:12 PM, Sean Heber wrote: > How about: > > let results = possibilities.where(matching: closure) > My understanding is that we're restricting the bikeshedding here to the closure label. Renaming `filter` is discussed in another thread, though obviously that would change t

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

On Wed, Jun 22, 2016 at 7:52 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0104: Protocol-oriented integers" begins now and runs > through June 27. The proposal is available here: > > > https://github.com/apple/swift-evolut

Re: [swift-evolution] Partial list of open Swift 3 design topics

On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone, > > Here is a partial list of the open topics that the core team would like to > get resolved in Swift 3. The list is partial both because I’m way behind > on swift-evolution traf

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 7:27 PM, Brent Royal-Gordon > wrote: > > I think you're tremendously overcomplicating the design. This isn’t intended as a proposed design. It is intended to start a discussion exploring the design space. > >> If we’re going to consider alternative designs it is worth

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 6:41 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 22 2016, Matthew Johnson > wrote: > >>> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Wed Jun 22 2016, David Waite wrot

Re: [swift-evolution] Stdlib closure argument labels and parameter names

How about: let results = possibilities.where(matching: closure) :) l8r Sean Sent from my iPad > On Jun 22, 2016, at 8:00 PM, Xiaodi Wu via swift-evolution > wrote: > > filter(extractingWhere:) >> On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution >> wrote: >> >> on Wed Jun

[swift-evolution] Partial list of open Swift 3 design topics

Hi everyone, Here is a partial list of the open topics that the core team would like to get resolved in Swift 3. The list is partial both because I’m way behind on swift-evolution traffic, but also because new things may come up. There are also a number of accepted proposals that are not yet

Re: [swift-evolution] Stdlib closure argument labels and parameter names

filter(extractingWhere:) On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Jun 22 2016, Xiaodi Wu wrote: > > > I'll duly oblige with some pushback on `suchThat`. I get that you're > trying > > to clarify whether filter retains or gets r

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

Hello Swift community, The review of "SE-0104: Protocol-oriented integers" begins now and runs through June 27. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md Reviews are an important part of the Swift evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Isn't this more caused by confusion about how infinite sequences work? The prefix one is no longer an infinite sequence. The second one still is. The second one will always infinite loop unless you break Brandon Sent from my iPad > On Jun 22, 2016, at 5:28 PM, Erica Sadun via swift-evolution

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 4:43 PM, Matthew Johnson wrote: > > On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > protocol _IntegerLiteralSyntax {} > enum Syntax { > typealias IntegerLiteral = _IntegerLiteralSyntax > } > > And used like this: > > struct Int : Syntax.IntegerLiteral {} > > > Is an

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote: > That's a really interesting idea. Is "Syntax" a placeholder, or is that the > intended name? It is the best name we could come up with, we are open to better suggestions. > Also, why an enum? Especially one without any cases... It is not

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

I think you're tremendously overcomplicating the design. > If we’re going to consider alternative designs it is worth considering the > semantic space available. For the sake of discussion, here is a model that > captures the various semantics that exist (the names are just strawmen): > >

Re: [swift-evolution] Revisiting SE-0041 Names

That's a really interesting idea. Is "Syntax" a placeholder, or is that the intended name? Also, why an enum? Especially one without any cases... Was all this already discussed in a thread that I missed (or have otherwise forgotten about)? - Dave Sweeris Sent from my iPhone > On Jun 22, 2016,

Re: [swift-evolution] Revisiting SE-0041 Names

on Wed Jun 22 2016, Matthew Johnson wrote: >> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> > > > >> wrote: >>> Proposal: >>> https://github.com/apple/swift-evolution/blob/master/

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Wed Jun 22 2016, Xiaodi Wu wrote: > I'll duly oblige with some pushback on `suchThat`. I get that you're trying > to clarify whether filter retains or gets rid of elements that match the > predicate, but I don't think "filter such that" expresses this idea at all. > > Comparing to "filter whe

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

> Le 22 juin 2016 à 12:27, Brandon Knope via swift-evolution > a écrit : > > I really don’t understand why we are wasting everyone’s time debating this. > > Yes I think there is a correlation. Yes this is precisely why I posted the > heat map. > > Of course \ is not needed a lot, but when it

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko wrote: > > On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md >> >> Re

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Wed Jun 22 2016, Matthew Johnson wrote: >> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 22 2016, David Waite wrote: >> > >>> Today, a Sequence differs from a Collection in that: >>> >>> - A sequence can be infinitely or indefinitely sized

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I'll duly oblige with some pushback on `suchThat`. I get that you're trying to clarify whether filter retains or gets rid of elements that match the predicate, but I don't think "filter such that" expresses this idea at all. Comparing to "filter where," "filter such that" is equally susceptible to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0103: Make non-escaping closures the default

> * What is your evaluation of the proposal? +11. This is a much better default. Escaping closures impose additional complexity on callers which should only be introduced when necessary. I am extremely unconvinced by the primary opposing argument that it should not be a breaking chan

Re: [swift-evolution] Stdlib closure argument labels and parameter names

on Tue Jun 21 2016, Dave Abrahams wrote: > on Mon Jun 20 2016, Brent Royal-Gordon wrote: > >>> A couple of weeks ago we started to notice that we had some poorly-named >>> closure parameters and argument labels in the standard library, so we >>> did a complete audit of the standard library's AP

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 6:12 PM, John McCall wrote: > >> On Jun 22, 2016, at 2:42 PM, Matthew Johnson > > wrote: >>> On Jun 22, 2016, at 4:29 PM, Javier Soto >> > wrote: >>> >>> I'll work on a formal proposal for sealed by default :) >>

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

> We sometimes review proposals from framework teams like Apple and LibDispatch Sorry, that should have been "Foundation and LibDispatch". -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swif

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

> PROPOSING: Update WatchKit API Design to use properties instead of methods to > set properties swift-evolution does not control how specific Apple frameworks, like WatchKit, get exposed to Swift. We sometimes review proposals from framework teams like Apple and LibDispatch on how they want to

Re: [swift-evolution] Swift 3 vs "additive" proposals

Sent from my iPad > On Jun 22, 2016, at 5:01 PM, Javier Soto wrote: > > Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the > proposal already: https://github.com/apple/swift- > evolution/pull/376 > I would be happy to work with you on improving the proposal. I think y

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 2:42 PM, Matthew Johnson wrote: >> On Jun 22, 2016, at 4:29 PM, Javier Soto > > wrote: >> >> I'll work on a formal proposal for sealed by default :) > > I have already been planning a proposal for sealed (in general) but didn’t > think it fit w

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

Doing this would require a larger change in Swift than a single API. WKInterfaceLabel is "one-way" in the sense that those values can be set with setter methods, but there is no API to get the values back. This can't map to properties in Swift as they're implemented today, because a property with a

[swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

PROPOSING: UPDATE WATCHKIT API DESIGN TO USE PROPERTIES INSTEAD OF METHODS TO SET PROPERTIES by Michie - https://github.com/michieriffic INTRODUCTION WKInterfaceLabel is still using methods for set Text (setText), set Text Color (setTextColor), set Attributed Text (setAttributedText) to set

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

Could we have a BufferedSequence type that is identity in most cases? On Thursday, 23 June 2016, Andrew Bennett wrote: > I agree that there should be a type for a non-destructive re-entrant > sequence. > > IIRC in past discussions one of the counter arguments given was IO stream > sequences. It

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

I agree that there should be a type for a non-destructive re-entrant sequence. IIRC in past discussions one of the counter arguments given was IO stream sequences. It is likely undesirable to buffer the entire stream, but without buffering there's no guarantee of getting the same values. These di

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 22 2016, David Waite wrote: > >> Today, a Sequence differs from a Collection in that: >> >> - A sequence can be infinitely or indefinitely sized, or could require >> an O(n) operation to count the val

Re: [swift-evolution] Swift 3 vs "additive" proposals

Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the proposal already: https://github.com/apple/swift- evolution/pull/376 I would be happy to work with you on improving the proposal. I think your mention to sealed protocols is super interesting, but I think that could be addi

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 4:29 PM, Javier Soto wrote: > > I'll work on a formal proposal for sealed by default :) I have already been planning a proposal for sealed (in general) but didn’t think it fit with the goals of Swift 3 anymore (I had forgotten about the plan to make sealed the default).

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

As I understand it, UTF-8 for POSIX APIs is always (usually?) valid on macOS, valid on Linux _IF_ your LANG etc. are set to C or en_US.UTF-8, and of questionable validity on Windows. Is the stdlib possibly converting to the "system encoding" underneath and possibly silently dropping characters i

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > As you will see from earlier messages, the confused user is both quite real > and *is* on this list. Nor, mind you, are pedagogical concerns to be > trivialized; they are serious concer

[swift-evolution] SE-0103: Make non-escaping closures the default

I agree with this proposal. In my own code I’ve found non-escaping parameters to be far and away the most common I create, with only the very occasional block that could escape. Most times when I’ve seen escaping blocks in the wild it’s in Apple’s frameworks — which makes sense, because Apple’s

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

I thought of this myself at one point, but I looked at a list of other languages to see if they did it and, if so, how much it actually improved anything. The only language I could find that I have experience in which does this outside of closures was Bash shell scripting, and there wasn’t much

Re: [swift-evolution] Swift 3 vs "additive" proposals

I'll work on a formal proposal for sealed by default :) On Wed, Jun 22, 2016 at 1:43 PM John McCall wrote: > On Jun 22, 2016, at 1:38 PM, Matthew Johnson > wrote: > > On Jun 22, 2016, at 11:48 AM, John McCall wrote: > > On Jun 22, 2016, at 9:15 AM, Javier Soto wrote: > How would we evaluate t

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution > wrote: > > As you will see from earlier messages, the confused user is both quite real > and *is* on this list. Nor, mind you, are pedagogical concerns to be > trivialized; they are serious concerns for the design of the language.

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

> The review of "SE-0103: Make non-escaping closures the default" begins now > and runs through June 27. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md > * What is your evaluation of the proposal? H

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

> * What is your evaluation of the proposal? I’m strongly in favor - improvements on retain cycle issues are a huge win, and escaping as the default better fits the visual layout of the code and forces the developer to think more for the case that’s more conceptually complicated instead o

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Wed Jun 22 2016, David Waite wrote: > Today, a Sequence differs from a Collection in that: > > - A sequence can be infinitely or indefinitely sized, or could require > an O(n) operation to count the values in the sequence. The latter being no different from Collection. > A collection has a

Re: [swift-evolution] [Review] SE-0095: Replace `protocol` syntax with `Any`

> The review of "SE-0095: Replace `protocol` syntax with `Any`" > begins now and runs through June 27. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md > > * What is your evaluation of the proposal? I th

Re: [swift-evolution] Revisiting SE-0041 Names

On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris wrote: > >> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution >> wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> wrote: >> >> Hi Erica, >> >> I would like to re-state the feedback from Dave Abrahams

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

> On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution > wrote: > Welcome, Logan. > > Functions currently return the empty tuple, ‘()’, by default. Void is a > typealias to the empty tuple type. It is also possible to write ‘return ()’ > explicitly, rather than just ‘return’. (This

Re: [swift-evolution] Revisiting SE-0041 Names

on Wed Jun 22 2016, David Sweeris wrote: >> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution >> wrote: >> >> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution >> wrote: >> > >> Hi Erica, >> >> I would like to re-state the feedback from Dave Abrahams, Max Moi

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 1:38 PM, Matthew Johnson wrote: >> On Jun 22, 2016, at 11:48 AM, John McCall > > wrote: >> >>> On Jun 22, 2016, at 9:15 AM, Javier Soto >> > wrote: >>> How would we evaluate the proposal to introduce the "sealed" specif

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 11:48 AM, John McCall wrote: > >> On Jun 22, 2016, at 9:15 AM, Javier Soto > > wrote: >> How would we evaluate the proposal to introduce the "sealed" specifier for >> classes (open within module, final outside of module) and default to that, >

[swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

Welcome, Logan. Functions currently return the empty tuple, ‘()’, by default. Void is a typealias to the empty tuple type. It is also possible to write ‘return ()’ explicitly, rather than just ‘return’. (This is generally a detail of the language, so may be unfamiliar) It is unclear in your pr

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

> On Jun 22, 2016, at 3:14 PM, Jordan Rose wrote: > >> >> On Jun 22, 2016, at 13:05, Matthew Johnson > > wrote: >> >> >>> On Jun 22, 2016, at 12:59 PM, Jordan Rose >> > wrote: >>> I would really like to see submodules, b

Re: [swift-evolution] [Review] SE-0095: Replace `protocol` syntax with `Any`

> * What is your evaluation of the proposal? +1. It sets the stage for some very desirable type system features in the future. There has already been extensive discussion on the topic and I don’t have anything new to add. > * Is the problem being addressed significant enough to w

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

> On Jun 22, 2016, at 13:05, Matthew Johnson wrote: > > >> On Jun 22, 2016, at 12:59 PM, Jordan Rose > > wrote: >> >>> >>> I would really like to see submodules, but I think there would still be >>> valid uses for `fileprivate` even with them. But of course we

Re: [swift-evolution] IUO in Swift 3.0

> On Jun 22, 2016, at 1:03 PM, Chris Lattner wrote: > >> On Jun 22, 2016, at 8:56 AM, Joe Groff wrote: >>> I think that there is some confusion here: it is true that IUO exists >>> internally as a type within the compiler, but the idea of our current >>> implementation is that that is just an

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

> On Jun 22, 2016, at 12:59 PM, Jordan Rose wrote: > >> >> I would really like to see submodules, but I think there would still be >> valid uses for `fileprivate` even with them. But of course we would need to >> know the details of submodules to have a good discussion about that so it’s >>

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

> Am 22.06.2016 um 10:39 schrieb Goffredo Marocchi : > > Sorry, but can you explain why the character used to escape strings is > also the best choice to do Variable value extraction/String interpolation? > They are two different concepts. They are two different concepts in the same way

Re: [swift-evolution] IUO in Swift 3.0

> On Jun 22, 2016, at 8:56 AM, Joe Groff wrote: >> I think that there is some confusion here: it is true that IUO exists >> internally as a type within the compiler, but the idea of our current >> implementation is that that is just an implementation detail within the >> compiler (similar to LV

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

> On Jun 22, 2016, at 12:37 PM, Ben Rimmington wrote: > But the cString(using:) method is from Foundation, and using UTF-8 should > always succeed in any case. I suppose you’re right about that, but now it brings up more confusion in my mind about what’s in Foundation and what’s in the standar

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol` syntax with `Any`

On Wed, Jun 22, 2016 at 12:34 PM Scott James Remnant via swift-evolution < swift-evolution@swift.org> wrote: > Have given this a thorough review, both the final proposal, and its > development during the draft phases on the list, etc. > > Unfortunately I have to give the final proposal as it stand

Re: [swift-evolution] Swift *less* safe than C for imported API that uses opaque struct pointers

> On Jun 22, 2016, at 11:20 AM, Timothy J. Wood via swift-evolution > wrote: > > > Currently, APIs that get imported with COpaquePointer make Swift *less* safe > than C. Fixing this seems like a breaking change, since it would change the > meaning of existing code that uses COpaquePointer.

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution > wrote: > > Hi Erica, > > I would like to re-state the feedback from Dave Abrahams, Max Moiseev > and me from the last time this was discussed.

Re: [swift-evolution] [Review] SE-0095: Replace `protocol` syntax with `Any`

On Wed, Jun 22, 2016 at 11:04 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0095: Replace `protocol` syntax with > `Any`" begins now and runs through June 27. The proposal is > available here: > > > https://github.com/apple/

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 1:40 PM, Xiaodi Wu via swift-evolution > wrote: > > Quick thoughts: > > Isomorphic is a delightful word. > > Initializing has the wrong meaning, I think. If A conforms to BInitializing, > that reads to me like you can do B(A), not necessarily A(B). By contrast, > BInit

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

I support this proposal for similar reasons. > covariance of using such a non-returning function as an argument This is the key feature of this proposal. In the earlier discussion, someone gave an example of a Runnable protocol, having one function which returns an associated type, and a second

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

> On Jun 22, 2016, at 12:04, David Waite wrote: > > >> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> I would really like to see submodules, but I think there would still be >>> valid uses for `fileprivate` even with the

[swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

I believe Swift should no longer require an explicit return on all functions and instead do an implicit nil return if the function reaches the end of its control flow and has an optional return type. This could be useful to keep code clean and compact, by only having to write code for cases tha

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

> On 22 Jun 2016, at 20:02, Kenny Leung via swift-evolution > wrote: > > I think it would be OK if the transparent bridging called cString(using:) > itself, and the whole thing would fail if the conversion fails. But the cString(using:) method is from Foundation, and using UTF-8 should alway

  1   2   3   >