Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

s to be allowed in both > identifiers and operators? > >> On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution >> > <

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 6:36 PM, Matthew Johnson via swift-evolution > wrote: >>> >>> I agree that requiring this is not likely to result in improved error >>> handling and thus is not a strong argument in favor of it. >>> >>> IMO the purpose of requiring “try” to be

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

hat would allow a quicker cadence > and more testing of new library and language features. It's seems to be > working well with Rust so far, at least. Anything is possible, we’re always open to good ideas. -Chris > > On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution &

Re: [swift-evolution] Asserts should not cause undefined behaviour

> On Dec 31, 2015, at 1:56 PM, Dave Abrahams wrote: >>> 2) Adding asserts to code should not make the code more dangerous whatever >>> the build. Assuming the truth of the assert may lead to runtime safety >>> checks being skipped and undefined behaviour when a no-op would

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution wrote: > Under what criteria should we propose moving items into the standard library > and out from the standard library into Swift Foundation? Or will these things > eventually merge and become one grand

Re: [swift-evolution] Closure Syntax

> On Jan 1, 2016, at 2:21 PM, Ethan Diamond wrote: > > FWIW I don't think the backlash to the use of ^ with Obj-C blocks was because > of the carat itself, Fair enough, different people have different objections. I’m sure some people love blocks syntax :-) > but

Re: [swift-evolution] Swift-Native Alternative to KVO

On Jan 1, 2016, at 5:00 PM, Jared Sinclair via swift-evolution wrote: > The one-to-many observer pattern could really use a first-party, native Swift > solution. The day-to-day practice of writing iOS / OS X applications needs > it, and we end up falling back on

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

On Jan 1, 2016, at 2:13 PM, Erica Sadun wrote: > Thanks Chris. I want to figure out what the guiding principles are before I > blow any further proposal-capital. This gives me a good place to start > chewing on some thoughts. In particular, I'm considering two scenarios.

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

> On Jan 1, 2016, at 3:32 PM, Rod Brown wrote: >> Thanks Chris. I want to figure out what the guiding principles are before I >> blow any further proposal-capital. This gives me a good place to start >> chewing on some thoughts. In particular, I'm considering two

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

> On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution > wrote: > > Everyone, > > The sticking point here is that xcode generates the first syntax > automatically. > > Simply filing a radar about this would be useless, so I believe the original >

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution wrote: > Hi all, > > I'm curious how other members of the Swift community feel about the clarity > of the "Double" and "Float" type names. It seems incongruous that the default > type for integers is

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On Jan 6, 2016, at 12:01 AM, Goffredo Marocchi wrote: > > Hello Chris, > > When dealing with floating point values, wouldn't it be in our best interest > to always be very specific about the accuracy of the floating point type > variables we use regardless of the device

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

On Jan 5, 2016, at 4:09 PM, Jordan Rose via swift-evolution wrote: >> We have some declaration modifiers (e.g., access-control modifiers) and >> attributes (e.g., availability) that distribute in this manner from the >> extension to its members. My only hesitation

Re: [swift-evolution] STDLibs

This is a complicated topic, I’d suggest asking on swift-users or swift-dev since it isn’t related to language evolution. -Chris > On Jan 6, 2016, at 10:47 AM, James Campbell via swift-evolution > wrote: > > Chris do you think there is scope for this ? > > On

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

> On Jan 5, 2016, at 10:57 AM, Dennis Lysenko > wrote: > > Chris, interesting tidbit. I wasn't aware of that. Is sourcekit considered to > be within the scope of the swift-evolution mailing list? No, it would be better to discuss it on swift-dev. -Chris

Re: [swift-evolution] Pitch: "while" clause on for-loops

> On Dec 31, 2015, at 12:42 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Currently, for-loops admit a "where" clause: > > for x in seq where cond { > ... > } > > behaves like > > for x in seq { > if !cond { continue } >

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 1:22 PM, Kevin Ballard wrote: > > A uniquely-owned class that guarantees stack allocation is pretty much the > same thing as a move-only value type, isn't it? The only real difference I > can think of is classes allow for subclassing. At this point, we’re

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution > wrote: > > >> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution >> > wrote: >> >> An alternative solution is to do what Rust

Re: [swift-evolution] Proposal: Support constant expressions in enum case raw values.

> On Dec 31, 2015, at 1:46 PM, Amir Michail via swift-evolution > wrote: > > Example: > > enum A : [Int] { >case B = [1,2,3] > } > > > Currently, the following error occurs: "raw value for enum case must be a > literal” A more typically requested example is

Re: [swift-evolution] Closure Syntax

On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution wrote: > There are three pieces at play here IMHO: > 1. How functions (global and on types) are declared and implemented > 2. How function specifications are indicated as types > 3. How anonymous functions

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution > wrote: > > I also think that Float and Double are not ideal type names but I also agree > with many of the concerns that have been raised. > > > Why not simply use (the existing) Float32 and

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

> On Dec 21, 2015, at 10:52 AM, Joe Groff wrote: > >> >> -1 >> >> “inout” is intended to communicate (or at least hint at) the copy-in / >> copy-out behavior of the argument. It is also there to enable other >> parameter modifiers, which can enable other more advanced

Re: [swift-evolution] Lambda function syntax

> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution > wrote: > > Does anyone not like the current syntax for this? > > I would propose changing it from: > > { (param_list) -> return_type in … } > > to something cleaner like: > > (param_list) ->

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution > wrote: > >> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution >> > wrote: >> >>> On Dec 19, 2015, at 5:09 PM, Brent

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

>>> >>> Is there an underlying reason that parameter modification should live on >>> the name side rather than the type side of the colon? They aren't really >>> modifying the name >>> >>> -- Erica, inexperienced with Rust >>>

Re: [swift-evolution] Lambda function syntax

> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro wrote: > > Hi Chris, > > Don’t you think the suggestion is better? I’m happy to formula it in terms of > an E(BNF) grammar if you like. Is this published/available anywhere, for the > current version of Swift? My personal

Re: [swift-evolution] Lambda function syntax

> On Dec 21, 2015, at 2:44 PM, Alexander Regueiro wrote: > > Okay, I assume you are aware this essentially the same syntax as used in > languages like C# and Python, yes? I’m not sure there are any problems in > those languages with it. > >> If you dig through (very early)

Re: [swift-evolution] Proposal: Improve switch control flow substituting fallthrough with a more safe one

> On Dec 21, 2015, at 11:57 AM, Jacopo Andrea Giola > wrote: > > Hi Chris, > > well now after some debate in the old thread and the flaws highlighted there > I’ve wrote e different proposal and narrowed the changes to only make > fallthrough respect the

Re: [swift-evolution] [Proposal idea] Support for pure functions

/llvm.org/docs/LangRef.html#id671 -Chris > > On Mon, Dec 21, 2015 at 2:55 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On Dec 19, 2015, at 9:00 PM, Jimmy Sambuo via swift-evolution > <swift-evolution

Re: [swift-evolution] [Proposal idea] Support for pure functions

> On Dec 21, 2015, at 12:05 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote: > > On Mon, Dec 21, 2015 at 11:55 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > …there probably has to be some way t

Re: [swift-evolution] Lambda function syntax

On Dec 21, 2015, at 2:26 PM, Alexander Regueiro wrote: > Thanks for clarifying. > > In that case, I would propose grammar for capture expressions, which should > drop in without modifications elsewhere (I say tentatively): > > closure-expression → “func"

Re: [swift-evolution] [Proposal] Property behaviors

On Dec 22, 2015, at 9:08 AM, Joe Groff wrote: >>> >>> I think there’s value for users in being able to group and scope the >>> components associated with a particular behavior, so IMO it’s worth it. >>> Overall, it makes usage of the language less complex in practice. >> >>

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 8:46 AM, Matthew Johnson wrote: > > Hi Chris, > > I have given your feedback a lot of thought and have taken another run at > this proposal from a slightly different angle. I believe it is a significant > improvement. Hi Matthew, I continue

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 9:59 AM, David Owens II wrote: > > >> On Dec 22, 2015, at 9:43 AM, Matthew Johnson wrote: >> >> Adding a new member to a struct is itself a breaking change. I don’t see >> how memberwise initialization makes this worse. > > It

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> The proposal already states that a memberwise initializer only includes >>> parameters for properties that are at least as visible as the initializer >>> itself. So if you can see

Re: [swift-evolution] Coroutine for Swift

Hi Susan, As I mentioned on your original pull request, coroutines are closely related to async and other concurrency forms. That entire space is out of scope for Swift 3, so we should wait until fall 2016 to pick up discussion on this and related topics. -Chris > On Dec 22, 2015, at 12:16

Re: [swift-evolution] Community Proposal: "This Week In Swift" newsletter

> On Dec 22, 2015, at 9:29 PM, Kevin Ballard via swift-evolution > wrote: > > During the development of Rust prior to v1.0, one of the things that really > helped with keeping up with changes (both in the language and in the stdlib) > was Corey Richardson's weekly

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 11, 2015, at 8:11 AM, Daniel Hooper via swift-evolution > wrote: > > A very common pattern in swift code is to "guard let" or "if let" optionals > - this works by creating a new non-optional variable to be used by future > code. Often, the new variable is

Re: [swift-evolution] Shift operator: the type of the second operand

> On Dec 19, 2015, at 7:43 PM, Jordan Rose via swift-evolution > wrote: > > +1 to dropping the existing signatures and providing a consistent right-hand > side. > > I'm a little concerned about not allowing Int as the shift type. Even though > we disallow negative

Re: [swift-evolution] [Proposal] Factory Initializers

zer model even MORE complex :-) but it is probably still the right way to go. -Chris > > -Thorsten > >> Am 18.12.2015 um 01:25 schrieb Chris Lattner via swift-evolution >> <swift-evolution@swift.org>: >> >> >>> On Dec 17, 2015, at 1:41

Re: [swift-evolution] Proposal: Add .times method to Integer type

> On Dec 18, 2015, at 12:32 PM, Radosław Pietruszewski > wrote: > >> >> My personal opinion on this is that 5.times { stuff} offers no benefits over >> “repeat 5 { stuff }”, so I’d rather see the later (if anything). >> >> This is all shades of gray with no clear answer.

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

> On Dec 18, 2015, at 3:03 PM, Stephen Canon wrote: > > >> On Dec 18, 2015, at 5:57 PM, Chris Lattner > > wrote: >> >> On Dec 18, 2015, at 1:12 PM, Stephen Canon via swift-evolution >>

Re: [swift-evolution] [Proposal] Property behaviors

On Dec 18, 2015, at 3:56 PM, Kevin Ballard via swift-evolution wrote: > Ultimately, I would love to have non-copyable structs in Swift. But the only > way to really do that is to have references in the language (otherwise the > moment you call a method on a

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

On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution wrote: >> >> One potentially large downside is you can no longer look at a type >> declaration and find out how large it is. For example, I could define >> >> struct Foo { >> var x: Int >> } >> >> and

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

> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution > wrote: > > For Swift 3, we're planning to phase out 'var' parameters in functions, and > we're also making it so that language keywords are valid argument labels. > With both of these changes pending, I

Re: [swift-evolution] Closure Syntax

> On Dec 27, 2015, at 2:30 PM, Ethan Diamond via swift-evolution > wrote: > > I realize this is on the commonly rejected list, but I really find closure > syntax to be one of the more unintuitive and unreadable parts of Swift so I'd > like to try to influence it.

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

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(_: “ >> and “thing.foo(:” are both unambiguously

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

On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution wrote: >> can be correctly parsed as a reference to insertSubview(_:at:). However, it >> breaks down at the margins, e.g., with getter/setter references or >> no-argument functions: >> >> extension Optional

Re: [swift-evolution] Lambda function syntax

Yes, please do. It is perfectly fine to disagree on technical points, but please do so with respect. -Chris > On Dec 27, 2015, at 3:44 PM, Austin Zheng via swift-evolution > wrote: > > Please treat your fellow contributors with respect and equanimity. > > Best, >

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

> On Dec 27, 2015, at 4:27 PM, John McCall wrote: > >> 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

Re: [swift-evolution] Beef up Imports

> On Dec 26, 2015, at 9:12 PM, Developer via swift-evolution > wrote: > > I opened a radar a while ago about improving the import syntax in Swift and > haven’t received much of a response, so I’ll try to expand on my thoughts in > there here. > > I’ve always been

Re: [swift-evolution] [Proposal] Property behaviors

> On Dec 21, 2015, at 6:06 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Dec 21, 2015, at 5:33 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Dec 21, 2015, at 5:21 PM, Jordan Rose wrote: >>>

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

On Dec 23, 2015, at 10:25 AM, Dave Abrahams wrote: >> Of the three, I prefer “associatedtype”. >> >> We already have precedent for concatenated names in a very related sort of >> decl (typealias), and this will be a real keyword. >> >> >> Here are how I see the pros and

Re: [swift-evolution] Mixins

Correct, there is just a lot of infrastructure work blocking it from happening at the moment, not lack of desire. -Chris > On Dec 23, 2015, at 11:57 AM, Stephen Celis via swift-evolution > wrote: > > I remember reading another thread (the associated/typealias

Re: [swift-evolution] Brace syntax

> On Dec 19, 2015, at 5:58 PM, Kevin Ballard via swift-evolution > wrote: > > There is not in fact an emphasis on conciseness. This has been repeated many > times by the swift team. Conciseness is not a goal of Swift, but > expressiveness absolutely is. Braces are

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Dec 29, 2015, at 8:02 PM, Trent Nadeau via swift-evolution wrote: > Doing this manually is possible using `defer` statements among other options, > but this is error prone as a `defer` can be forgotten, `lock`/`unlock` calls > for two locks can be switched due to

Re: [swift-evolution] Add conversion String -> Bool

> On Jun 4, 2016, at 7:22 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> It would be great if we had `init?(_ text: String)` for Bool class. Because >> sometime when you're processing JSON/XML it can help you a lot. > > Way ahead of you: >

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

> On Jun 3, 2016, at 10:34 PM, Austin Zheng 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 > later this year? I would *love* to get it in

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

Hello Swift community, The review of the revised proposal SE-0089: "Renaming String.init(_: T)" begins now and runs through June 7. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Reviews are an

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 31, 2016, at 4:02 PM, Hooman Mehr via swift-evolution > wrote: > > This arises a different question: Should `description` always return the same > value? For example: Can `description` of “May 31th, 2016” return “Today” if > we evaluate it today and return

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

On Jun 2, 2016, at 9: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 context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > > Nonetheless,

Re: [swift-evolution] Philosophy of Swift

> On Jun 8, 2016, at 6:03 AM, Jonathan Hull via swift-evolution > wrote: > > I am (somewhat unexpectedly) teaching a class in Swift/iOS starting later > this week, and I was hoping to get a couple of quotes to share with my > students from the community (and

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

> On Jun 8, 2016, at 7:52 AM, Brent Royal-Gordon wrote: > >> Is there a widely used comparison function that throws? > > Any comparison function that examines external data related to the instance: > > * Sorting filenames by the data in the corresponding files > *

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

> On Jun 7, 2016, at 12:07 PM, Tim Vermeulen via swift-evolution > wrote: > >> True, but the cost of being able to restore the original ordering, when >> that restoration may not be needed at all, is prohibitive. > > What about simply restoring the elements, in no

Re: [swift-evolution] SE-0045 status?

> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution > wrote: > > Did we ever get to a stopping point on SE-0045, with the take while / drop > while methods? I remember we were discussing using prefix / suffix and a > bunch of other names, but was the

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

> On Jun 1, 2016, at 11:29 PM, Jacob Bandes-Storch wrote: > > On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner > wrote: > On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch >

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

On Jun 5, 2016, at 8:24 PM, T.J. Usiyan via swift-evolution wrote: > Sub typing is the answer that we're going with then? Most likely. At this point, we’re not really accepting additive changes to Swift 3 anyway, so any proposal would need to wait until post-swift 3

Re: [swift-evolution] SE-0045 status?

> On Jun 7, 2016, at 9:54 PM, Erica Sadun wrote: > > >> On Jun 7, 2016, at 9:37 PM, Chris Lattner wrote: >> >> >>> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> Did we ever get to a

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

> On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution > wrote: > > Since this seems to have some interest, I've made a gist. > > https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c >

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

> On May 25, 2016, at 8:39 PM, Kevin Ballard via swift-evolution > wrote: > > On Thu, May 19, 2016, at 05:52 PM, Kevin Ballard wrote (on a different > thread): >> After having given this some thought, it seems apparent that >> `sequence(state:next:)` is equivalent

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

On Jun 8, 2016, at 7:27 PM, Brent Royal-Gordon via swift-evolution wrote: > However, if-let does not permit the analogous construct: > > guard let (x, y, z) = (foo(), bar(), bas()) else { > > Now that we're moving away from allowing compound if-lets, I think it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 12:11 PM, Joe Groff wrote: > > Hello Swift community, > > The review of SE-0099 “Restructuring Condition Clauses” begins now and runs > through June 3, 2016. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution > wrote: > I am not a fan of this syntax. `;` reads very strongly as a statement ender > to me, Technically speaking, Swift uses semicolon as a separator, not a line ender. We already use it to

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On May 26, 2016, at 9:40 PM, Austin Zheng via swift-evolution wrote: >> Some remaining open questions: >> >> - Exactly what types should conform to ValuePreservingStringConvertible. It >> seems clear that integer, floating point types, and Character can and should

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 12:13 AM, Patrick Smith via swift-evolution > wrote: > A different train of thought: could semicolons allow the closure ambiguity to > be resolved that Chris brought up a couple of months ago? e.g. > I imagine it wouldn’t, as the parser would

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On May 27, 2016, at 9:10 PM, Jacob Bandes-Storch via swift-evolution wrote: > Does "lossless" preclude floating-point numbers from being printed in decimal > unless they are exactly representable? No, FP types should be able to conform. There are algorithms that are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution wrote: >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> wrote: >>> • What is your evaluation of the proposal? >> >> +1. I believe it improves the

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 27, 2016, at 7:50 PM, Patrick Smith via swift-evolution > wrote: > > Is there any possibility we can break from this? Especially as: > > 1. ValuePreservingStringConvertible expects its description to be value > preserving, but current Cocoa implementations

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: > >>> >>> Given the whole newline groundswell that has emerged on SE, I did consider >>> it but when I mocked up examples, it felt less readable and I suspect it >>> would negatively affect the clarity of parsing

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: > > What about requiring `let` before each binding and `case` before each pattern? > > guard case let x = a, case let y = b, let z = c, x == y else { … } > > Now `let z = c` can only be a let-binding and not a pattern

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 27, 2016, at 8:51 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I've put together a preliminary v2 of the proposal, taking into account > feedback expressed on this thread. I would appreciate any comments, > suggestions, or

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 28, 2016, at 10:46 PM, Patrick Smith wrote: > > Thanks for replying Chris! > >> On 29 May 2016, at 6:00 AM, Chris Lattner wrote: >> >> 2) If a value wants a better, or more customized, string form, then it >> conforms to

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Fantastic, thanks to both of you. I merged it here: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Please let me know if you’d like any

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 29, 2016, at 3:55 AM, Haravikk wrote: >>> On May 27, 2016, at 12:11 PM, Joe Groff >> > wrote: >>> >>> Hello Swift community, >>> >>> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs

Re: [swift-evolution] [Pitch] #warning

> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution > wrote: > > I appreciate the sentiment, but I think we should reserve warnings for > actual compiler diagnostics. +1. The IDE should just pick up "// FIXME: “ comments and summarize them as

[swift-evolution] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md Hello Swift Community, The review of SE-0050: "Decoupling Floating Point Strides from Generic Implementations" ran from May 17...23, 2016. The proposal is returned for revision: There

[swift-evolution] Core team review process update

The core team has caught up except for three proposals that have gone through the review period, but which haven’t been decided yet: The details of SE-0086 are still being discussed. The proposal overall is certain to be approved, but the specific list of affected types may or may not change.

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution > wrote: > > well there is no macro system, and for the moment a clear statement from > chris that this is not on the table in the short term. the code in the > example looked like run-of-the-mill

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

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md The review of "SE-0089: Renaming String.init(_: T)" ran from May 17…23, 2016. The proposal has been *returned for revision* and another round of discussion - the core team would

[swift-evolution] [Deferred to later in Swift 3] SE-0083: Remove bridging conversion behavior from dynamic casts

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md The review of "SE-0083: Remove bridging conversion behavior from dynamic casts" ran from May 10…16, 2016. The proposal has been *deferred* for re-evaluation later in Swift

[swift-evolution] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0094-sequence-function.md The review of "SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib" ran from May 19…23, 2016. The proposal has been *accepted* with one minor naming-related change:

[swift-evolution] [Deferred] SE-0090: Remove .self and freely allow type references in expressions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md The review of "SE-0090: Remove .self and freely allow type references in expressions" ran from May 17…23, 2016. The proposal has been *deferred* from Swift 3. The community and core team all

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

> On May 30, 2016, at 3:09 PM, Erica Sadun wrote: > You can't splat but you can decompose a tuple by assignment: Right. That is because assignment permits destructuring. Parameter lists do not (anymore). -Chris ___

Re: [swift-evolution] Variadic generics discussion

This is very close to my priority list. That said, I think that all of these are out of scope for swift 3 sadly. After Swift 3, the priority list will be driven by what the standard library needs to get its APIs realized in their ideal form (eg without any of the _ protocol hacks).

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 6:05 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On May 31, 2016, at 12:49 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On May 31, 2016, at 12:17 PM, L Mihalkovic via

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> On May 31, 2016, at 6:20 PM, Joe Groff wrote: >> If the goal was to remove magic from the compiler, then a possible direction >> would be to do something like: >> >> 1) Introduce a new declmodifier named something like “atomiclazy”. >> 2) Disallow global and static

Re: [swift-evolution] [Pitch] #warning

On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution wrote: >> One may argue that the comment-based markings can be handled by the IDE, but >> IMO transferring language features onto IDE is wrong. These comments do not >> appear anywhere within the log when

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md Hello Swift Community, The review of SE-0098: "Lowercase didSet and willSet for more consistent keyword casing" ran from May 24…30, 2016. The proposal is *rejected* for Swift 3. The

[swift-evolution] [Accepted with Revision] SE-0098: Converting dynamicType from a property to an operator

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md Hello Swift Community, The review of SE-0098: "Converting dynamicType from a property to an operator" ran from May 24…30, 2016. The proposal is *accepted* for Swift 3. The feedback on the

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md Hello Swift Community, The review of SE-0097: "Normalizing naming for "negative" attributes" ran from May 24…30, 2016. The proposal is *rejected* for Swift 3. The core team agrees with

  1   2   3   4   5   6   7   8   9   10   >