Re: [swift-evolution] Better syntax for deferred?

> On Jan 4, 2016, at 12:41 PM, Howard Lovatt via swift-evolution > wrote: > I don’t think it is worth changing from defer to the more traditional try > finally block, both have pros and cons. Just work with what we have. You can > always, as a matter of style, put a

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 28, 2015, at 1:14 PM, Joe Groff wrote: >> On Dec 28, 2015, at 1:09 PM, Brent Royal-Gordon >> wrote: >> >>> and you could access the unapplied lens for an instance property using >>> `Type.property` syntax, analogous to how `Type.method`

Re: [swift-evolution] Why aren't source to source transformations part of the Swift language standard?

> On Dec 29, 2015, at 11:40 AM, Amir Michail via swift-evolution > wrote: >> On Dec 29, 2015, at 2:34 PM, Jacob Bandes-Storch > > wrote: >> >> I would not recommend phrasing these proposals as "Why doesn't Swift already

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 21, 2015, at 11:19 AM, Jordan Rose via swift-evolution > wrote: >> On Dec 21, 2015, at 10:27 , Joe Groff > > wrote: >> >> >>> On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution >>>

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 23, 2015, at 7:05 AM, Paul Cantrell <cantr...@pobox.com> wrote: > On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> >> when you stuff a lot of functionality into a single class in most OO >> la

Re: [swift-evolution] Readwrite reflection in Swift

> On Dec 17, 2015, at 11:21 PM, Gergely Orosz via swift-evolution > wrote: > (forwarding a discussion on Swift reflection from swift-users) > > It seems there is no disagreement on how reflection is something we would > want in Swift. Given that until this is part of

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution > wrote: > On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > > wrote: >>> can be correctly parsed as a reference to

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

I prefer this solution, > but if it is rejected for whatever reason we should at least explicitly > outlaw A(literal) syntax in favor of "literal as A". > > Austin > > On Thu, Jun 2, 2016 at 9:08 AM, John McCall via swift-evolution > <swift-evolution@swift.o

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

integer type like UInt16, we will recognize that the coercion always traps and emit an error at compile-time, but this generally won't apply to other types. John. > > On 02.06.2016 19:08, John McCall via swift-evolution wrote: >> The official way to build a literal of a specific type is to

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

nge >> of values for UIntN. If the literal is in the legal range for an Int but >> not for the target type, this might trap at runtime. Now, for a built-in >> integer type like UInt16, we will recognize that the coercion always traps >> and emit an error at compile-time, but this

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

> On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon wrote: >> In my opinion, using this initializer-call syntax to build an >> explicitly-typed literal is an obvious and natural choice with several >> advantages over the "as" syntax. However, even if you disagree, it's

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

> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xen...@gmail.com> wrote: >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I still think the value-based APIs a

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

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xen...@gm

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

problem should be addressed one way or another. I prefer this solution, >> but if it is rejected for whatever reason we should at least explicitly >> outlaw A(literal) syntax in favor of "literal as A". >> >> Austin >> >> On Thu, Jun 2, 201

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

> 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 consistency. For example, wasn't it clarified on this > list just recently that literals don't have a type and adopt one based

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

> On Jun 2, 2016, at 10:31 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> The official way to build a

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

@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>>> On Jun 2, 2016, at 4

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

> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: > on Tue Jun 07 2016, John McCall wrote: > >>> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >>> wrote: >>> on Thu Jun 02 2016, John McCall >>

Re: [swift-evolution] Philosophy of Swift

> On Jun 8, 2016, at 8:35 AM, J. Charles M. N. via swift-evolution > wrote: > +1 Brandon > Sound like the first real fully open source language. This is not fair to any number of other languages. We're proud of how open the Swift development process is, but we can't

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution > wrote: >> @escaping would be part of the parameter type just as @noescape is today. >> Your foo(closure:) example wouldn't compile with my proposal, the same as >> today if you marked the

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

> On Jun 8, 2016, at 11:15 AM, Dave Abrahams wrote: > on Wed Jun 08 2016, John McCall wrote: > >>> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: >>> on Tue Jun 07 2016, John McCall wrote: >>> > On Jun 5, 2016, at 5:18 PM, Dave Abrahams via

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

> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jun 02 2016, John McCall > wrote: > >> The official way to build a literal of a specific type is to write the >> literal

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

> On Jun 4, 2016, at 11:54 AM, Chris Lattner <clatt...@apple.com> wrote: > On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The official way to build a literal of a sp

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution > wrote: > on Wed Jun 08 2016, Brent Royal-Gordon > wrote: > >>> I'm not sure that these ideas are consistent with the Swift >>> error-handling philosophy, which IIUC

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolutioneers, > > Here's an idea. It's technically additive, but it's small and I think it fits > in well with Swift 3's goals, one of which is to establish API conventions. >

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: > on Thu Jun 09 2016, John McCall wrote: > >>> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution >>> wrote: >>> on Wed Jun 08 2016, Brent Royal-Gordon >>

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 3:17 PM, Trent Nadeau wrote: > When would be a good time to actual put out a PR to the swift-evolution repo > for this proposal? The feedback so far has been very light, but I'm not sure > if that's because everyone's gearing up for WWDC, if there's

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 4:15 PM, Jordan Rose wrote: >> On Jun 9, 2016, at 16:10, John McCall > > wrote: >> >>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution > wrote: > > I'm against this for library evolution reasons: if someone releases a version > of their library that has a non-escaping closure and later discovers it needs > to be escaping, they can't

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

> On Jun 3, 2016, at 5:31 PM, Ben Rimmington via swift-evolution > wrote: > John McCall wrote: > >> I think that's a very promising way of thinking about literals. Writing >> a literal creates a notional value whose type is the informal, infinite- >> precise type of

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

> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 8:11 PM, John McCall wrote: >> >>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >>> On Jun 3, 2016, at 6:23 PM, John McCall

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

> On Jun 3, 2016, at 8:11 PM, Ben Rimmington wrote: > I think your original proposal is good, but just in case: > > [Currently] > >// Literal `7` is converted to `Swift.IntegerLiteralType` typealias. >UInt16(7) calls UInt16.init(_ value: Int) > > [Suggested] >

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

> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: > On Jun 3, 2016, at 6:23 PM, John McCall wrote: > On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution

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

esent a couple of examples >>>>> where such initialization(like UInt16(7)) can produce some unexpected >>>>> behavior / error at runtime? >>>> >>>> UIntN has unlabeled initializers taking all of the standard integer types, >>>>

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

> On Jun 2, 2016, at 6:48 PM, Matthew Johnson <matt...@anandabits.com> wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu &

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 12, 2016, at 9:08 PM, Charlie Monroe wrote: >> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution >> > wrote: >> >> Unavailable doesn't mean un-callable. >> If you're marking an

Re: [swift-evolution] Remove nil and NilLiteralConvertible

> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution > wrote: > (No joking) > Points: > > 1. When nil was added to the language, we could not infer enumeration type: > if x != Optional.none { ... } > > Now it looks like this: > if x != .none { ... } > > If

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

> On May 29, 2016, at 6:38 AM, Thorsten Seitz wrote: > An, now I see what you mean. You are right, P ::= ∃ t : P . t is a > constrained existential type defining a subtype relationship. > Thanks for enlightening me! > > I haven’t perceived a protocol as an existential up to

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

> On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution > wrote: > This is unfortunate, because then the meaning of "existential" and > "non-existential" in Swift are just the opposite of their respective meaning > in standard terminology :-( I don't know

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

The official way to build a literal of a specific type is to write the literal in an explicitly-typed context, like so: let x: UInt16 = 7 or let x = 7 as UInt16 Nonetheless, programmers often try the following: UInt16(7) Unfortunately, this does not attempt to construct the value

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

> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > wrote: >> 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 >>

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

e top of my > head, but I’m not convinced that means they don’t exist. I do not think that anybody writes UInt64(0) and *wants* the 0 to be built as an Int and then coerced to UInt64. John. > > So… I’m tentatively -1 > > - Dave Sweeris > >> On Jun 2, 2016, at 11:08 AM,

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

> On Jun 2, 2016, at 11:22 AM, Matthew Johnson wrote: > On Jun 2, 2016, at 12:01 PM, John McCall > wrote: > >>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution >>>

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

> 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, in > terms of source-code compatibility? > From my point of view it

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

> On Jun 22, 2016, at 9: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 >>>

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

> On Jun 22, 2016, at 12:15 AM, L. Mihalkovic via swift-evolution > wrote: > > Func asOpt(v:Any) -> Optional { > If let val = v as? T { > Return val > } > Return nil > } > Regards > LM > (From mobile) This is just: return v as? T John. > > On Jun 22,

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

> On Jun 22, 2016, at 7:59 AM, Erica Sadun via swift-evolution > wrote: >> On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution >> > wrote: >> >> Hi Everyone, >> >> As I mentioned before, the

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

> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution > wrote: > >> Rationalizing base conversion protocol names. I personally don't have the >> heart to try to re-address the "LiteralConvertible" protocol naming thing >> again but this would be the

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

d subclasses, no, there would not. John. > >> On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 22, 2016, at 9:15 AM, Javier Soto <javier@gmail.com &

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

> On Jun 22, 2016, at 9:12 AM, Charlie Monroe wrote: > > Please consider the following code: > > let myString: String? = "Hello" > let anyValue: Any = myString > let obj: AnyObject? = anyValue as? AnyObject // nil, since it's > Optional, String being struct, >

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swi

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 20, 2016, at 11:24 AM, Anton Zhilin via swift-evolution > wrote: > Trent Nadeau via swift-evolution writes: > >> https://github.com/tanadeau/swift-evolution/blob/make-noescape- > default/proposals/-make-noescape-default.md > > -1

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] Marking sort and sorted with rethrows

> On Jun 20, 2016, at 9:57 AM, Dave Abrahams wrote: > on Thu Jun 09 2016, John McCall wrote: > >>> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: >>> on Thu Jun 09 2016, John McCall wrote: >>> > On Jun 9, 2016, at 9:04 AM, Dave Abrahams via

Re: [swift-evolution] State of @noescape ?

> On Jun 20, 2016, at 10:55 AM, Антон Жилин via swift-evolution > wrote: > IIRC, there were at least the following counter-arguments: > 1. One must break API and ABI compatibility to add @escaping to an existing > function > 2. @nonescaping case is actually quite as

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution > wrote: > IIRC, some languages require zero-width joiners (though not zero-width > spaces, which are distinct) to properly encode some of their characters. I'd > be very leery of having Swift land on a

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 10:58 AM, Andrew Trick via swift-evolution > wrote: >> On Jun 24, 2016, at 8:19 AM, Matthew Johnson > > wrote: >> >> Andrew, thank you for working on this. The latest draft is much

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

> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution > wrote: >> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution >> > wrote: >> >>> On Jun 15, 2016, at 8:36 PM, Robert Widmann

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

> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution > wrote: > I replaced `precedencegroup` with `precedence` and added `Precedence` > suffix to all precedence group names. See: > > https://github.com/Anton3/swift-evolution/blob/fix-operator- >

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 30, 2016, at 3:11 AM, Jeremy Pereira via swift-evolution > wrote: >> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> In the low level world, there is no such thing as an invalid address; both >>>

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 24, 2016, at 9:43 PM, Chris Lattner <clatt...@apple.com> wrote: > On Mar 24, 2016, at 7:28 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> I'd actually be much more concerned about the pervasive assumptions about >> pointer

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 10:18 PM, Jacob Bandes-Storch wrote: > On Sat, Apr 16, 2016 at 5:20 AM, plx via swift-evolution > > wrote: > > > My 2c is that if this is to go in the standard library, it should be done >

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

> On Apr 25, 2016, at 10:32 AM, Douglas Gregor via swift-evolution > wrote: >> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution >> > wrote: >> >> Hi Brent, >> >> Thanks for your feedback!

Re: [swift-evolution] [swift-dev] Lazy var and deinit

> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev > wrote: > Should SWIFT initialize a variable in deinit method if it has not been > initialized? > > For example: > ```swift > class A { > lazy var b = B() > deinit { > b.clean() >

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 10:50 PM, John McCall > wrote: > > I have not been following this discussion, but I would be extremely antsy > about guaranteeing any

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall > wrote: >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > >

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

> On Apr 28, 2016, at 11:10 AM, Chris Lattner via swift-evolution > wrote: > Hello Swift community, > > The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and > runs through May 3. The proposal is available here: > > >

Re: [swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: > The problem can be solved by modifying that code. Thanks you. I thought that > code will affect only to the CLong type not Int. It changes what 'long' gets imported as. If there's a Windows API defined using 'long'

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution > wrote: >> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution >> > wrote: >>> On May 20, 2016, at 10:25, John McCall

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 20, 2016, at 10:46 AM, Erica Sadun wrote: >> On May 20, 2016, at 11:42 AM, John McCall > > wrote: >> >>> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 17, 2016, at 8:30 PM, Chris Lattner via swift-evolution > wrote: > Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The proposal is available here: > > >

Re: [swift-evolution] Make access control private by default.

> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution > wrote: > > I was just about to mention this too. I think it's interesting that > one can write a simple application in Swift without having to worry > (much) about visibility of elements. Please

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

> On May 24, 2016, at 11:21 AM, Joe Groff via swift-evolution > wrote: > didSet and willSet are already contextual rather than formal keywords, and > there's a conceivable future where didSet and willSet are no longer keywords > at all if we run with the "property

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On May 20, 2016, at 1:25 PM, Антон Жилин wrote: > Inline: > > 2016-05-20 20:58 GMT+03:00 John McCall >: > The transitivity rule plus the ability to define precedence relationships in > both directions on a new

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 14, 2016, at 10:16 PM, Chris Lattner via swift-evolution > wrote: > On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution > wrote: >>> This encourages the use of empty closures over optional closures, which I >>> think is

Re: [swift-evolution] Make access control private by default.

> On May 15, 2016, at 12:15 PM, Knut Lorenzen via swift-evolution > wrote: > I think internal as default is bad, because it discourages encapsulation. > > Building scalable software components relies on hiding implementation details > to create layers of abstraction.

[swift-evolution] [Review] Amendment: SE-0039: Moderning Playground Literals

Original proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md Pull request for modification: https://github.com/apple/swift-evolution/pull/324

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution > wrote: >> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote: >> >> At what point would you consider the Linux product to be viable for >>

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

> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> wrote: >> >> We’ve had this kind of thing come up before, too, with the >> Linux/FreeBSD/Android

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

> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution > wrote: > I was just thinking that: > protocol Foo : reference {} > might be more to the point than: > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* >

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > wrote: >> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Pattern binding for optionals will look like: >>> >>> if let x? = y { ... } >> >>

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 11:47 AM, Chris Lattner <clatt...@apple.com> wrote: > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >>> <

Re: [swift-evolution] [Idea] Remove optional pattern binding

016, at 11:47 AM, Chris Lattner <clatt...@apple.com > > <mailto:clatt...@apple.com>> wrote: > > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> > >>

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:35 PM, Chris Lattner wrote: >> On May 2, 2016, at 1:19 PM, John McCall > > wrote: >> >>> On May 2, 2016, at 12:13 PM, Антон Жилин >> > wrote: >>> I

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 2:17 PM, David Hart wrote: > John, > > When the core team implemented the `if let x? = y` experiment and later > backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as > nice as it sounds, it didn’t work out in practice.” sounds

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

> On May 3, 2016, at 9:22 AM, Michael Buckley via swift-evolution > wrote: > I may be fundamentally misunderstanding the Windows Subsystem for Linux, but > I believe it just provides binary compatibility for Linux x86_64 command-line > tools, but doesn't quite

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

> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: > On Apr 14, 2016, at 10:40 PM, John McCall wrote: To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 15, 2016, at 1:29 AM, Milos Rankovic > wrote: >> On 15 Apr 2016, at 03:22, John McCall > > wrote: >> Your JSON literal example is already pretty well modeled by simply making a >> JSONValue type that

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 12:01 PM, Milos Rankovic via swift-evolution > wrote: > Hi Andrey and Laurent, > >> On 14 Apr 2016, at 19:23, Andrey Tarantsov > > wrote: >> >> Can you please give us a few real-world examples

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 1:34 PM, Milos Rankovic > wrote: > Hi John, > >> On 14 Apr 2016, at 21:09, John McCall > > wrote: >> >> I mean, you could just make your Tree type implement all the individual >>

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon > wrote: >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> out of it. > > That not only doesn't work if your type

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:03 PM, Milos Rankovic > wrote: >> On 14 Apr 2016, at 21:36, John McCall > > wrote: >> >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and

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

> On Apr 15, 2016, at 10:41 AM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Apr 14, 2016, at 10:50 PM, Chris Lattner <clatt...@apple.com> wrot

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

> On Apr 15, 2016, at 2:47 PM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 15, 2016, at 11:43 AM, John McCall <rjmcc...@apple.com> wrote: >>> On Apr 15, 2016, at 10:41 AM, Joe Groff <jgr...@apple.com> wrote: >>>> On Apr 15, 2016, at 8:29 AM, John M

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:56 PM, Milos Rankovic > wrote: > Hi John and Brent, > >> On 14 Apr 2016, at 22:22, John McCall > > wrote: >> >> multiple-conformance idea doesn't work > > > The idea is not

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

> On Apr 14, 2016, at 10:28 PM, Chris Lattner wrote: > > On Apr 14, 2016, at 10:21 PM, John McCall wrote: >> >>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> We currently accept function

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

> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wanted to treat > all

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

> On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution > wrote: > -1. This feels like a band-aid rather than a well-considered fix to the > issues raised in the proposal. I don't see what makes operators as a class of > functions more or less susceptible to

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution > wrote: > As Jordan mentioned, I don't (and I think other people don't) think of > extensions as their own entities, as they can't be referred to and have no > runtime representation. In that mental

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jul 21 2016, John McCall > wrote: > >>> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution >>>

  1   2   3   4   5   >