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

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

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

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

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

, 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 write the &g

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

> On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I still think the value-based APIs are misleading and that it would be >> better to a

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

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 >> mailto:swift-ev

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

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 > mailto:swift-evolution@swift.org>> wrote: > The

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 >>> mailto:swift-evolution@swift.org>> wrote: On Jun 2, 2016, at 10:38 AM, Xiaodi Wu >>

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

t 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, John McCall via swift-evolution

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 >> type(of:), so we're going from a "magic" property to a "mag

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

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

> 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 now, probably because

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

> 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 what you mean by this. The

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 behaviors" feature again in th

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 note I'm talking about > applic

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 precedence group allows a new precedence group to > cre

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 >>> mailto:swift-evolution@swift.org>> wrote: On May 20, 2016, at 11:34 AM, Jordan Rose

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: > > > https://github.com/apple/swift-evolution/blob/master

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 >> mailto:swift-evolution@swift.org>> wrote: >>> On May 20, 2016, at 10:25, John McCall >> > wrote: >>> On May 19, 2016, at 4

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

> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution > wrote: >> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] [Pitch] Nesting types without nesting in place (additional)

> On May 18, 2016, at 11:00 AM, Adrian Zubarev via swift-evolution > wrote: > May I revive this idea for a discussion. > > When I posted this first I didn’t thought about creating these nested types > inside extensions. > > So basically I could do this (over and over): > > extension SomeClas

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. It’s a fundamental principl

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 open for debate. In general I try to avoid optionals when

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 >> production server side application development. Do you th

[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] #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 group vs. the OSX/iOS/watchOS/tvOS group, or with >> 32-bi

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 implement enough of the Linux sysc

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 very definite, as > i

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 absolutely agree with John, and I think, we should push this through

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

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

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

> On May 2, 2016, at 11:47 AM, Chris Lattner wrote: > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > wrote: >> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >>> wrote: >>>> On May 1, 2016, at 13:09, Brent

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 { ... } >> >> I suggested precisely this in February. The core team

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* > reference-semantics type of

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: > > > https://github.com/apple/swift-evolution/blob

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

> On Apr 26, 2016, at 1:39 PM, Joe Groff wrote: >> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution >> wrote: >> >>> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: >>> The problem can be solved by modifying that code. Thanks you. I thought

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' (rather than some more mean

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Brent, >> >> Thanks for your feedback! You’ve got some great questions below, I’ll try to >> answer

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 > > wrote: >> On Fri, Apr 22, 2016 at 10:50 PM, John McCall >

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 particular representation for the set of values.

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 > mailto:swift-evolution@swift.org>> wrote: > > > My 2c is that if this is to go in the standard library, it should be done > “right”, which would be more like this version of

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() > } > } > var a = A() >

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

> On Apr 15, 2016, at 2:47 PM, Joe Groff wrote: >> On Apr 15, 2016, at 11:43 AM, John McCall wrote: >>> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >>>> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >>>> wrote: >>>> &g

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

> On Apr 15, 2016, at 10:41 AM, Joe Groff wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> wrote: >> >>> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: >>> On Apr 14, 2016, at 10:40 PM, John McCall wrote: >>>>&g

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 conforms to all the literal protocols. It is completely >

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 transform/predicate where this most commo

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 type syntax without parentheses, like: > >> To me, the unparenthesi

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 functions as taking a single

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 multiple-conformance (or overloading), but multiple (two) > initial

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 isn't a LiteralConvertibl

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 it implements the latter by building a Value >> ou

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 >> literal-convertible protocols. > > It does sound like something l

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 where initializing a >> nontrivial tree-like data

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

> On Apr 6, 2016, at 9:21 AM, Brent Royal-Gordon via swift-evolution > wrote: >>> Interesting, but I’m unsure if all of it is significantly better than just >>> using the guard that is effectively inside of the operator/func that is >>> being proposed: >>> >>> guard let value = Int("NotANumber

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 >>> 0x0 and ~0x0 are perfectly valid byte pointers. So usi

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

> On Mar 24, 2016, at 9:43 PM, Chris Lattner wrote: > On Mar 24, 2016, at 7:28 PM, John McCall via swift-evolution > wrote: >> I'd actually be much more concerned about the pervasive assumptions about >> pointer representation in Clang and LLVM than I would be with S

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

> On Mar 24, 2016, at 3:50 PM, Brent Royal-Gordon via swift-evolution > wrote: >> Thirdly, as mentioned in the prior discussion it's certainly possible on >> some platforms to remap the memory page at address 0x0 and make it usable to >> userland code. Even if we don't currently support any suc

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 single defer block at the en

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` works. I feel like >>> if we did that, then it

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 >> support X?" when you are proposing a new feat

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

> } > > let fn5 = someA.#someOtherFunc(a:, b:) > let fn6 = someA.#someOtherFunc() > let fn6 = someA.someOther > > Another possibility: > > let fn5 = #(someA.someOtherFunc(a:, b:)) > let fn5 = @(someA.someOtherFunc(a:, b:)) > > Thus the parser can try to just

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

> On Dec 27, 2015, at 4:15 PM, Chris Lattner wrote: > > On Dec 27, 2015, at 4:09 PM, John McCall wrote: >>> I’m a fan of good error recovery, but I don’t think it is a major concern >>> here for two reasons: >>> >>> 1) The most common case in a method will lack a label, and "thing.foo(_: “ >>

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 > mailto:swift-evolution@swift.org>> wrote: >>> can be correctly parsed as a reference to insertSubview(_:at:). However, it >>> breaks down at the margins, e.g

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

> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > wrote: >> Getters and setters can be written using dotted syntax within the back-ticks: >> >> let specificTitle = button.`currentTitle.get` // has type () -> String? >> let otherTitle = UIButton.`currentTitle.get` // has type (UIBu

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

>>>> >>>>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson >>>>> wrote: >>>>> >>>>> >>>>>>> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution >>>>>>> wrote: >>>&

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

> On Dec 24, 2015, at 11:48 AM, Matthew Johnson wrote: >> On Dec 24, 2015, at 1:31 PM, John McCall wrote: >> >> >>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson >>> wrote: >>> >>> >>>>> On Dec 23, 2015, at 12:50 P

Re: [swift-evolution] Pitch: Copy constructors for structs

> On Dec 23, 2015, at 2:18 PM, Félix Cloutier via swift-evolution > wrote: > The "when exactly are copy constructors run" and "when is the compiler > allowed to elide copies" parts are very important and not always obvious in > current Swift code. For instance: > >> struct Point { >> var

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

> On Dec 23, 2015, at 10:51 AM, Matthew Johnson wrote: > > >> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution >> wrote: >> >>> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: >>> On Dec 22, 2015, at 10:45 PM, John McCall via swi

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

> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: > On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution > wrote: >> >> when you stuff a lot of functionality into a single class in most OO >> languages, there’s no real way to enforce its division into su

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

> On Dec 22, 2015, at 7:40 PM, Jordan Rose wrote: >> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution >> wrote: >> >> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution >> wrote: >>>> >>>> One poten

Re: [swift-evolution] rethrows as first-class type annotation

> On Dec 21, 2015, at 6:09 PM, Jordan Rose wrote: > John, IIRC you had some reason why this wasn't a great idea, but I can't > remember it. It seems useful to me too, if not something that comes up too > often. I don’t remember off-hand. I think it’s theoretically supportable, but it adds ext

swift-evolution@swift.org

> 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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Sat, Dec 19

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

> On Dec 18, 2015, at 4:19 PM, Kevin Ballard wrote: > On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: >> I think any storage-in-extensions proposal ought to be a special feature of >> classes; I would not support the ability to add stored properties to structs >> in extensions, even from w

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

> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution > wrote: > On Fri, Dec 18, 2015, at 03:15 PM, Joe Groff via swift-evolution wrote: >> >>> On Dec 18, 2015, at 12:49 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> I only see the benefits on this. • We don

Re: [swift-evolution] do try catch?

> On Dec 7, 2015, at 8:30 PM, Liam Butler-Lawrence via swift-evolution > wrote: > Hi Kame, > > Thanks for the work you put into this! I’ll give my thoughts on each proposed > syntax: > >> // First syntax: >> guard let >> bar = bar, // Has to be non-nil >> try foo("Hello"),

Re: [swift-evolution] [Proposal] Replace thin arrows (->) with fat arrows (=>)

> On Dec 18, 2015, at 9:35 AM, David Fekke via swift-evolution > wrote: > In wanted to propose either adding the fat arrow (=>), or replacing the thin > arrow with the fat arrow. > > I know that Java uses the thin arrow, but JavaScript, TypeScript and C# both > allow the use of the fat arrow

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 the language, it will be a

<    1   2   3   4   5