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] Swift 3 vs "additive" proposals

actually, other than the >>>>> spelling of the modifier. It's something we probably ought to commit to >>>>> in Swift 3, though. >>>> >>>> By “commit to in Swift 3” do you mean that it is likely the core team >>>> would introduce a p

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

gh. >>>>> >>>>> By “commit to in Swift 3” do you mean that it is likely the core team >>>>> would introduce a proposal for this in Swift 3? >>>> >>>> We might be able to put the decision off as part of the larger resilien

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] [Proposal] Generic and `throw`ing subscripts

> On Jun 22, 2016, at 9:11 AM, plx via swift-evolution > wrote: > > >> On Jun 22, 2016, at 8:28 AM, T.J. Usiyan > > wrote: >> >> plx: wouldn't the same overload resolution strategy be appropriate here? >> "most

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

> * What is your evaluation of the proposal? -1. I prefer the MemoryLayout struct approach that Dave Abrahams has suggested. The proposed names retain the the disadvantage of several top level names and introduce a new disadvantage that they are not directly related to familiar terms

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

Sent from my iPad > On Jun 21, 2016, at 5:51 PM, Jordan Rose via swift-evolution > wrote: > > >> On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution >> wrote: >> >>> On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via

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

Sent from my iPhone > On Jun 20, 2016, at 1:10 PM, Robert Widmann via swift-evolution > wrote: > > Good morning all. Attached is the proposal Harlan Haskins and I will be > submitting shortly about adding generic and `throw`ing subscript declarations > to the

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

> On Jun 16, 2016, at 10:36 AM, Paul Cantrell via swift-evolution > wrote: > >> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >> Protocols are a mechanism for deriving

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 10:20 AM, Robert Widmann wrote: > > > > ~Robert Widmann > > 2016/06/16 8:18、Matthew Johnson > のメッセージ: > >> >>> On Jun 16, 2016, at 10:12 AM, Robert Widmann

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 10:12 AM, Robert Widmann wrote: > > The Swift PM case is actually the one that causes me to sound the alarm bells > ;) I migrated that one by hand as did @modocache for XCTest. What I mean is that you just applied the semantic-preserving

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 9:30 AM, Robert Widmann wrote: > > Find it under our own pull requests on apple/swift#3000 You mean this one: https://github.com/apple/swift/pull/3000 right? What specifically did you want me to look

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 9:23 AM, Robert Widmann wrote: > > Go checkout my branch! And see the discussion there for how your proposal > has impacted corelibs. I’ll be happy to. Can you please provide a link to the branch and discussion? > > ~Robert Widmann > >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 16, 2016, at 8:27 AM, Brent Royal-Gordon > wrote: > >> I am not convinced this is necessary. If there *is* a containing 'private' >> scope you can just leave the member unannotated to get this behavior. If >> there isn't you can use 'fileprivate' as it is

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Sent from my iPad On Jun 16, 2016, at 5:20 AM, Brent Royal-Gordon via swift-evolution wrote: >> 6. With the core team tied up at WWDC, you may want to temporarily forbid >> the use of `private` on a type and revisit the matter when people are less >> busy; if

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

y properties on the type will effectively inherit the access level of >> that type, unless the type’s access level is broader than “internal”. For >> the example of a private type at the top level of a file, its properties >> will effectively be fileprivate. >> >> Charles >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

ileprivate. Agree. This is exactly what I have been saying. > > Charles > >> On Jun 15, 2016, at 5:48 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPad >> >>> On Jun 15, 2016

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Sent from my iPad > On Jun 15, 2016, at 5:17 PM, Robert Widmann wrote: > > I await their opinions I as well. :) > , but even with that change we still have a problem with the philosophy here. > The motivation behind the fileprivate/private distinction is, as you

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >>> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu <xiaodi...@gmail.co

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote: >> >>> On Jun 15, 2016, at 2:46 PM, Adrian

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote: > >> On Jun 15, 2016, at 2:46 PM, Adrian

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:43 PM, Adrian Zubarev via swift-evolution > wrote: > > Shouldn’t a file act like an individual scope? If so why would A be visible > in C? Is it because files act not a lexical scopes? > > Did you mean that `C` is in a different file?

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution > wrote: > > I was referencing to the issue Robert discovered in his implementation. > > I do understand what the proposal is all about, but thank you for > re-clarifying that to me. :) > > I

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:29 PM, Robert Widmann wrote: > > The meaning of private according to the proposal is not scope-dependent, it > is decl-dependent. The mental gymnastics we are both going through right now > are not in the proposal. I would like them to be.

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:19 PM, Robert Widmann wrote: > > We have diagnostics specifically to prohibit this case. You cannot raise the > access level of members. > > private struct Foo { > internal var x : String = "" > } > > warning: declaring an internal var

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 2:04 PM, Robert Widmann wrote: > > > > 2016/06/15 11:47、Matthew Johnson > のメッセージ: > >> >>> On Jun 15, 2016, at 1:37 PM, Robert Widmann >>> wrote: >>> >>>

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Sent from my iPad > On Jun 15, 2016, at 1:51 PM, Robert Widmann wrote: > > Then it is no different from fileprivate. Yes, at file scope this is true. A reasonable argument can be made for prohibiting it at file scope for the sake of clarity, but if it is allowed

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 1:37 PM, Robert Widmann wrote: > > The scope of the *declaration* is not the issue. The scope of its *members* > is. Let’s consider an example: private struct Foo { var bar: Int } // elsewhere in the same file: var foo = Foo(bar: 42)

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

The scope for a top-level declaration is the file itself. This means that top-level declarations with `private` and `fileprivate` should have the same behavior. They should not be uninstantiable or unusable. -Matthew > On Jun 15, 2016, at 1:31 PM, Robert Widmann via swift-evolution >

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

Sent from my iPad On Jun 11, 2016, at 7:48 AM, Brent Royal-Gordon wrote: >> Functions and tuples are structural types, although it is probably possible >> to make tuples syntactic sugar for a Tuple type of we get the necessary >> variadic generics support. > > The

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

Sent from my iPad > On Jun 10, 2016, at 7:46 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jun 09 2016, Matthew Johnson > wrote: > >>> On Jun 9, 2016, at 3:05 PM, Dave Abrahams >>>

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

Sent from my iPad > On Jun 11, 2016, at 7:31 AM, Thorsten Seitz via swift-evolution > wrote: > > >>> Am 11.06.2016 um 14:23 schrieb Brent Royal-Gordon : >>> >>> The only magic would be that all type definitions (`protocol` etc.) which >>>

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

> On Jun 9, 2016, at 3:05 PM, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Matthew Johnson wrote: > >>> On Jun 9, 2016, at 11:42 AM, Dave Abrahams wrote: >>> >>> >>> on Thu Jun 09 2016, Matthew Johnson >> >

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 1:01 PM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution >> >: >> >>> >>> On Jun 9, 2016, at 7:04 PM, Jordan Rose

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

> On Jun 9, 2016, at 11:42 AM, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Matthew Johnson > wrote: > >>> On Jun 9, 2016, at 9:55 AM, Dave Abrahams >> > wrote: >>> >>> >>> on Wed

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

> On Jun 9, 2016, at 9:55 AM, Dave Abrahams wrote: > > > on Wed Jun 08 2016, Matthew Johnson > wrote: > >>> On Jun 8, 2016, at 1:33 PM, Dave Abrahams wrote: >>> >>> >>> on Tue Jun 07 2016, Matthew Johnson wrote:

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

pe > // But the concrete index types within each of the existential variables may > be different > doSomething(someSeq, anotherSeq) > > It's this situation (using an existential type to fulfill a generic type > parameter constrained to the same requirements that comprise that > existe

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

> On Jun 8, 2016, at 1:33 PM, Dave Abrahams wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams wrote: >>> >>> >>> on Tue Jun 07 2016, Matthew Johnson >> >

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

Sent from my iPad > On Jun 8, 2016, at 3:16 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 08 2016, Thorsten Seitz wrote: >> >> Ah, thanks, I forgot! I still consider this a bug, though (will have >> to read up again

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

> On Jun 7, 2016, at 9:27 PM, Matthew Johnson wrote: > >> >> On Jun 7, 2016, at 9:15 PM, Dave Abrahams > > wrote: >> >> >> on Tue Jun 07 2016, Matthew Johnson > > wrote: >> On

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

> On Jun 7, 2016, at 9:15 PM, Dave Abrahams wrote: > > > on Tue Jun 07 2016, Matthew Johnson > wrote: > >>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Tue Jun

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

> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> , but haven't realized >>> that if you step around the type relationships encoded in Self >>> requirements

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

> On Jun 7, 2016, at 12:51 PM, Dave Abrahams wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> On Jun 6, 2016, at 12:22 AM, Dave Abrahams >> wrote: >>> >>> >>> on Sun Jun 05 2016, Matthew Johnson > >

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

> On Jun 6, 2016, at 12:22 AM, Dave Abrahams wrote: > > > on Sun Jun 05 2016, Matthew Johnson > wrote: > >> Sent from my iPhone >> >>> On Jun 5, 2016, at 3:51 PM, Dave Abrahams via swift-evolution >>> wrote:

Re: [swift-evolution] Pitch: @required attribute for closures

that it is called >>>>> before being deinit-ialized. Failing that I'm happy with a runtime >>>>> circumstance in the cases the compiler can't check. >>>> >>>> Yeah, maybe if it is only used asynchronously and never stored in a member >>>

Re: [swift-evolution] Pitch: @required attribute for closures

n the cases the compiler can't check. >>>>>> >>>>>> Yeah, maybe if it is only used asynchronously and never stored in a >>>>>> member or global it could be verified and that is a pretty common case. >>>>>> That would certain

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On Jun 5, 2016, at 6:20 PM, Douglas Gregor wrote: > > >> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: >> >> I've put together a considerably more detailed draft proposal, taking into >> account as much of Matthew's

Re: [swift-evolution] Pitch: @required attribute for closures

is not the right >>>> attribute, but I'm not convinced @required is either. Maybe @invoked. >>>> >>>>> >>>>> It would be great if @required took into the account the feedback from >>>>> that proposal and conside

Re: [swift-evolution] Pitch: @required attribute for closures

;> dispatch_async(someQueue) { >>> let result: SomeEnum >>> // the compiler ensures 'result' is set >>> defer { completionHandler(result) } >>> >>> if aCondition { >>> if bCondition { >>> result = .F

Re: [swift-evolution] Pitch: @required attribute for closures

t; } > // the compiler ensures you do this, because it is 'let' > return > } > > if cCondition { > result = .Baz > } > } > } > >> On Sun, Jun 5, 2016 at 9:42 PM, Matthew Johnson via swift-evolution >> <swift-evoluti

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 5:02 AM, Patrick Pijnappel via swift-evolution > wrote: > > This has actually been proposed before, see SE-0073: > https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md Actually that proposal

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 4, 2016, at 10:27 AM, LM <laurent.mihalko...@gmail.com> wrote: > > > > On Jun 4, 2016, at 4:00 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Ju

Re: [swift-evolution] Ad hoc enums / options

ns I have with the original proposal and it is a lot simpler than structural subtyping. >> On Jun 3, 2016, at 5:10 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPad >> >>>>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

t;>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson <matt...@anandabits.com> wrote: >>>> On Jun 3, 2016, at 6:23 PM, John McCall <rjmcc...@apple.com> wrote: >>>> >>>>>>> On Jun 3, 2016, at 4:07 PM, David Sweeris <daveswee...@mac.com&

Re: [swift-evolution] Ad hoc enums / options

> >>> Le 3 juin 2016 à 16:20:18, Greg Parker via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>> >>>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org&

Re: [swift-evolution] [Proposal] Enum subsets

Sent from my iPad > On Jun 4, 2016, at 12:34 AM, Austin Zheng via swift-evolution > wrote: > > It seems like it would make sense to model enum subsets as a subtype > relationship. > > Is the core team planning on drawing up a structs/enums subtyping proposal >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

n 3, 2016, at 4:07 PM, David Sweeris <daveswee...@mac.com> wrote: >>>>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> Using an external parameter label in a de

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad On Jun 3, 2016, at 6:23 PM, John McCall <rjmcc...@apple.com> wrote: >>> On Jun 3, 2016, at 4:07 PM, David Sweeris <daveswee...@mac.com> wrote: >>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>> <swift-evolution@sw

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 3, 2016, at 6:44 PM, Erica Sadun wrote: > > >> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution >> wrote: >> What about the ABI? This sounds expensive to implement. >> >> Consider this set of ad-hoc

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 3, 2016, at 6:20 PM, Greg Parker <gpar...@apple.com> wrote: > > >>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>> On Jun 1, 2016, at 5:

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 4:05 PM, Brent Royal-Gordon wrote: > >> I am not the only one who feels that way. Quoting Brent: >> >> "But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I >> don't think that's a good idea. Parameter labels are supposed to

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 3:17 PM, John McCall wrote: > >> On Jun 3, 2016, at 12:41 PM, Matthew Johnson > > wrote: >>> On Jun 3, 2016, at 1:36 PM, John McCall >> > wrote: >>>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 1:36 PM, John McCall wrote: > >> On Jun 2, 2016, at 6:48 PM, Matthew Johnson > > wrote: >> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad On Jun 3, 2016, at 7:08 AM, Brent Royal-Gordon wrote: >> This might be silly, but what if there were a struct with all of the >> relevant fields (not sure what the best name would be): >> >> struct MemoryLayout { >> let size: Int >> let alignment:

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad >> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >> wrote: >> >> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu wrote: >> The IntegerLiteral type idea might be worth exploring. It does seem to >> provide some additional

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:57 PM, Sean Heber wrote: > > This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let size: Int > let alignment: Int > let

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution > wrote: > > Isn't this the same argument for .dynamicType over type(of:) though? > > Given that that debate has been settled in favor of the latter, I think the > question today is how

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution > wrote: > > On the other hand, on its own sizeof() is not unsafe, and so the argument > that it should be longer to call attention to itself (by analogy with > UnsafePointer) isn't

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad > On Jun 2, 2016, at 3:41 PM, John McCall wrote: > >>> On Jun 2, 2016, at 12:10 PM, Matthew Johnson wrote: >>> On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution >>> wrote: >>> >>> +1. >>>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 2:58 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> On Jun 2, 2016, at 1:30 PM, John McCall <rj

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 1:55 PM, Austin Zheng via swift-evolution > wrote: > > I think we should actually go further. > > If this proposal is accepted, disallow "as" as a way of specifying the type > to construct from a literal. I’m not sure. I agree it would be bad

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution > wrote: > > +1. > > The primary advantage is that it aligns the language semantics with how most > programmers expect this common C-language-family idiom to behave and removes > a potential source of

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 to this. It seems like a very straightforward thing to do. Sent from my iPad > On Jun 2, 2016, at 11:08 AM, John McCall via swift-evolution > wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 12:01 PM, John McCall <rjmcc...@apple.com> wrote: > >>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu <

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:04 AM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> struct MemoryLay

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:04 AM, Pyry Jahkola wrote: > >> Matthew Johnson wrote: >> >> Going with MemoryLayout *does not* mean we would have to give up the value >> functions if we don’t want to: >> >> struct MemoryLayout { >> init(t: T) { /* throw away the value */ }

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually possible to write your own > type(of:), so we're going from a "magic" property to a "magic" function at > least for now. No, but you *can* write `func foo(_ t: T)` which

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:01 AM, Charlie Monroe wrote: > >> Isn’t this a short-term concern? I thought that requirement was going away. > > AFAIK there are still concerns about ambiguity - [Int] - is it an array with > one element (Int.self), or is it [Int].self?

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu wrote: > > That proposal was returned for revision; as far as user ergonomics in Swift > 3, .self is going to be a consideration. Best to find a solution that reads > nicely regardless of the situation with .self removal. From the

Re: [swift-evolution] [swift-evolution-announce] [Rejected] SE-0097: Normalizing naming for "negative" attributes

> On Jun 2, 2016, at 9:52 AM, Sean Heber via swift-evolution > wrote: > > In terms of naming, I almost feel like “None” would be a better name for it > as then it reads somewhat as the opposite of “Any” and that has a nice > symmetry to me. + 1. Although the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 9:43 AM, Erica Sadun wrote: > > Supporting Dave A, type-based calls are much more likely to be used than > instance calls, unlike with dynamicType/type(of:) > > Term stdlib search gist search Google site:github +swift > sizeof157

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad On Jun 2, 2016, at 6:26 AM, Brent Royal-Gordon via swift-evolution wrote: >> /// Returns the contiguous memory footprint of `T`. >> /// >> /// Does not include any dynamically-allocated or "remote" storage. >> /// In particular, `size(of:

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad >> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith wrote: >> I really like this idea. This IMO is lower level functionality than >> `type(of:)` (née

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 12:05 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu wrote: >>> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution > wrote: > > > in other words, we could consider allowing this: > >func foo(bar: (.fit | .fill)) { > > baz(bar: bar) > >} > >func baz(bar: (.fit | .fill | .florp) { ...

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 1, 2016, at 4:38 PM, Tony Allevato via swift-evolution > wrote: > > I find myself agreeing with the idea that ad hoc enums are to enums as > structs are to tuples. Based on that analogy, why should an ad hoc enum > *need* a name

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

Sent from my iPad > On Jun 1, 2016, at 4:18 PM, Austin Zheng via swift-evolution > wrote: > > After thinking about this topic for the past few days, I'd like to throw in > my support for "Any<>" as well. It's one magic construct to learn, looks like > a type, has

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

Sent from my iPad > On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution > wrote: > > One thing I did often in Java (and miss in Swift) is using their enums to > build state machines or implement command patterns for common commands. > > Java enums are a

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 8:29 AM, Joe Groff wrote: > >> >> On Jun 1, 2016, at 6:26 AM, Matthew Johnson wrote: >> >>> >>> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution >>> wrote: >>> On May 31, 2016,

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution > wrote: > >> >> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: >> >> I agree that this is a better design for Swift than the monstrosity I >> started out with. >> >> The

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 1, 2016, at 1:55 AM, Austin Zheng via swift-evolution > wrote: > > Maybe it's overkill. My personal opinion is that breaking the symmetry of the > language like this (are there any other types of function arguments that > cannot be

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 31, 2016, at 7:10 PM, Chris Lattner wrote: > > This is very close to my priority list. That said, I think that all of these > are out of scope for swift 3 sadly. Happy to hear these priorities look about right to you also. (I realized

Re: [swift-evolution] Ad hoc enums / options

gether. IMO it is a reasonable “workaround” for now. I believe there is a lot of overlap between doing this the right way and introducing structural unions like those in Ceylon (fortunately there seems to be growing support for this). For that reason I think it makes sense to wait

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 3:39 PM, Austin Zheng wrote: > > (inline) > > On Tue, May 31, 2016 at 1:34 PM, Matthew Johnson > wrote: > >> On May 31, 2016, at 3:25 PM, Austin Zheng >

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 3:25 PM, Austin Zheng wrote: > > I have a proposal for #6 in the pipe, but there are actually some subtleties > I have to work out (it's not as simple as just slapping a generic type > signature on a let constant). Cool. Looking forward to

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution > wrote: > > This is pretty much where my thinking about the topic has led me as well. > I'll resign this topic to pursue some other, hopefully more relevant work, > although anyone who wants to

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 2:36 PM, Adrian Zubarev via swift-evolution > wrote: > >> Exactly. You are allowed to omit `return` if the entire body only consists >> of `return some().expression` > > Thats where the useless example comes in (but we don’t need this

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 2:13 PM, Adrian Zubarev via swift-evolution > wrote: > >> Please remove the section on guard as any of the preceding will never have >> single expression top level code blocks if they contain a guard clause. > > I didn’t get this at first but

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 1:11 PM, Austin Zheng via swift-evolution > wrote: > > AFAICT compile-time code generation suffers from the C++ templates problem - > my understanding is that if you don't have access to the definition of the > template you can't specialize. A

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 2:04 PM, Erica Sadun wrote: > >> >> On May 31, 2016, at 12:35 PM, Matthew Johnson > > wrote: >> >> I think I'm -1 on this. It makes things easier for the implementer of the >> function and

<    4   5   6   7   8   9   10   11   12   13   >