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

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

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

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

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 >> > wrote: >> >> >> on Wed Jun 22 2016, Matthew

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: >

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

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

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.

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

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

[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.

[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

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

[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

[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

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

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 > > wrote: >> Proposal: >>

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

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

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: > > >

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

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

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 >

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

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,

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

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

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 >>>

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

[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

[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: > >

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

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,

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 >> > > > >>

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.

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

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 > > wrote: >> Proposal: >>

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

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

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

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

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 >> >

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

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

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

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

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

[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

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

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,

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

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 >

[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

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

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

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?

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

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

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

> 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

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: >>

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: >> > >>

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

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 >>>

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 >>

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

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 >> > wrote: >> >>> >>> I would really like to see submodules, but I think there

[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

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,

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

on Wed Jun 22 2016, Erica Sadun wrote: >> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 22 2016, Erica Sadun wrote: >>> >>> No, I'd do edits on a gist page not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

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 stands a strong -1. While I appreciate the future benefits of more generic existential types, the final proposal

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

> On Jun 22, 2016, at 11:59 AM, 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

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

Thanks! Missed that. I think it would be OK if the transparent bridging called cString(using:) itself, and the whole thing would fail if the conversion fails. -Kenny > On Jun 22, 2016, at 11:52 AM, Ben Rimmington wrote: > > >> On 22 Jun 2016, at 17:37, Kenny Leung

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

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-conventions.md > > Rejection: "The feedback on the proposal was generally positive about the >

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

Not with this proposal, but this should be allowed at a later point. This would work as a workaround. protocol A { } protocol B { } typealias AB = A & B struct Foo : AB { } class SuperClass { } class SubClass : SuperClass, AB { } It’s up to the core team to decide if your mentioned behavior

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

> On 22 Jun 2016, at 17:37, Kenny Leung via swift-evolution > wrote: > > What does surprise me is that Swift String bridges directly into “char *” > arguments in C as nul-terminated C strings, apparently preserving unicode and > all. I can find nothing on bridging

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

> On Jun 22, 2016, at 11:47 AM, Jose Cheyo Jimenez wrote: > Would sealed classes be able to be (unsafely) casted as non sealed classes? Sealed-ness doesn't change the type. Casting doesn't come into it. If you're asking if there would be a way to unsafely add subclasses,

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

Would sealed classes be able to be (unsafely) casted as non sealed classes? > On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution > wrote: > >> On Jun 22, 2016, at 9:15 AM, Javier Soto > > wrote: >> How

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

> > * What is your evaluation of the proposal? My team just started using Swift a few weeks ago. But based on my experience in Objective-C and problems with retain cycles I really really like this proposal. Makes the code easier to grasp because by just reading it I know that that closure cannot

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

Could this ampersand syntax be reused in protocol adoption too? Idea: protocol A { } protocol B { } struct Foo : A & B { } class SuperClass { } class SubClass : SuperClass, A & B { } This would solve a problem: currently you cannot tell at a glance whether a class is a) inheriting from a

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

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, BInitializable conveys more clearly the sense that A can be initialized with an argument of type

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

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. A collection has a finite number of elements, and the fixed size is exposed as an O(1) or O(n) operation via

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

On Wed, Jun 22, 2016 at 9:37 AM, Kenny Leung via swift-evolution wrote: > Hi All. > > In the spirit of Chris’ focus on Swift 3 message… > > I’ve been working on calling C code that takes “const char * const *” > arguments, and it ain’t easy, but that can be left for a

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

> * What is your evaluation of the proposal? +1 I think this will help getting safer code by default along with already approved SE-0035 > * Is the problem being addressed significant

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

I've actually enjoyed this hidden feature on several occasions. It nicely allows you to interact with C APIs such as: system("rm -rf ~/*") Could you please elaborate a bit on the "hurting yourself" part? Do you mean e.g. C APIs falsely determining strlen due to the ability of String to contain

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

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. As a motivating example consider: import Darwin var state = copyfile_state_alloc()

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 22 2016, Erica Sadun wrote: >> >> No, I'd do edits on a gist page not in-place > > Then feel free, of course! It's your choice, y'know. I

[swift-evolution] Revisiting SE-0041 Names

Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md Rejection: "The feedback on the proposal was generally positive about the

[swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

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/swift-evolution/blob/master/proposals/0095-any-as-existential.md Reviews are an important

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

on Wed Jun 22 2016, Adrian Zubarev wrote: > Should there be a design guideline rule for colons : in Swift? > > I see people doing things like this: > > protocol A : B {} > > // VS. > > protocol A: B {} > func foo() -> T { … } > > // VS. > > func foo() -> T { … } > var

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

> > 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 a > topic for the future. :) > > I wonder what became of

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

on Wed Jun 22 2016, Erica Sadun wrote: >> On Jun 21, 2016, at 7:07 PM, Dave Abrahams wrote: >> >> >> on Tue Jun 21 2016, Erica Sadun > > wrote: >> > On Jun 21, 2016, at 6:06 PM, Dave Abrahams

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

> On Jun 22, 2016, at 10:09 AM, Matthew Johnson wrote: > >> >> On Jun 22, 2016, at 10:59 AM, John McCall > > wrote: >> >> >>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution >>>

  1   2   >