Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> > UnsafeBytePointer API for In-Memory Layout > > UnsafePointer and UnsafeMutable refer to a typed region of memory, and the > compiler must be able to assume that UnsafePointer element (Pointee) type is > consistent with other access to the same memory. See proposed Type Safe > Memory

Re: [swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

On May 19, 2016, at 10:26 PM, Dan Appel wrote: > Well, I am in full support then. Thanks for being patient here! No problem at all, thanks! -Chris > > On Thu, May 19, 2016 at 10:23 PM Chris Lattner > wrote: > On May 19,

Re: [swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Well, I am in full support then. Thanks for being patient here! On Thu, May 19, 2016 at 10:23 PM Chris Lattner wrote: > On May 19, 2016, at 10:17 PM, Dan Appel wrote: > > >Because it means that there is exactly one API: not a canonical API and > a

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Thats a fair solution. I still disagree, but not as strongly. On Thu, May 19, 2016 at 10:01 PM Krystof Vasa wrote: > With this proposal in place: > > 1) The user would type print(myURL.path). > 2) The compiler will immediately issue a warning about printing an > optional - the

Re: [swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

>Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this. Yes, but that's not really my point. Why do it this "magical" way? It's already possible (and actually very easy) to wrap C modules such as libdispatch in a Swifty API (see Venice

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

With this proposal in place: 1) The user would type print(myURL.path). 2) The compiler will immediately issue a warning about printing an optional - the user would hence learn about optionals *before* the code is run. 3) If he ran the code anyway, he'd still get Optional(/iphone/) anyway. 4)

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 19, 2016, at 9:46 PM, Austin Zheng wrote: > > P.S. On an unrelated note, it might be better to host a proposal in a Gist or > elsewhere; the first time I sent this message the mailing list software > caused it to bounce. I suspect the same might have happened

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

I think this is a good change with an admirable premise: that unsafety should not necessarily be a binary proposition - either avoid it completely, or use it and silently run into all sorts of potential UB pitfalls. (This is compounded by the problem that exactly what UB is is poorly understood

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

BTW - google for swift print optional stackoverflow. I think that kind of speaks for itself. > On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution > wrote: > > -1 > > This seems to me like crippling string interpolation just because sometimes > we make

Re: [swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

This is great! What will setTargetQueue and setTimer become? It would be great if the proposal doc could be updated with the API that was accepted. On Thu, May 19, 2016 at 9:03 PM Patrick Smith via swift-evolution < swift-evolution@swift.org> wrote: > Great stuff! Truly is a massive improvement

Re: [swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Great stuff! Truly is a massive improvement to an already venerable API. Was there any consideration to make this a new module ‘Dispatch’, and drop all the Dispatch- prefixes? Or rather, what is the reason for keeping the prefixes? (Group could become WorkGroup to lessen naming conflicts) >

[swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md Hello Swift Community, The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" ran from May 10…17, 2016. The proposal is *accepted with revisions* for Swift 3.

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

On Thu, May 19, 2016, at 05:59 PM, Patrick Smith wrote: > This sounds fair to me. I imagine a functional version would return > two item tuple instead of mutating, so would it be that similar to > what people expect? A functional version of `sequence(state:next:)` would indeed use the type

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

I think that is a little confusing and has potential to be ‘abused’. I think it’s more confusing that a `for(;;)` loop for instance, and that got removed. I think var + AnyIterator is more explicit, and can become the canonical way to do this. Hopefully AnyIterator can be optimized to the same

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

> I'm posting this on behalf of Dmitri Gribenko, and Max Moiseev, and > myself. > > We would like to accept the proposal with one modification: rather than > add an argument label, we'd like to drop the String initializer > altogether, making `"\(expression)"` the standard way to get a string >

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

> On May 19, 2016, at 6:52 PM, Kevin Ballard via swift-evolution > wrote: > > After having given this some thought, it seems apparent that > `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the > closure captures a single mutable variable. The

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

After having given this some thought, it seems apparent that `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the closure captures a single mutable variable. The microbenchmark performance may differ slightly, as the AnyIterator version will allocate a box on the heap to hold

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

It would certainly be clearer that the state is changing on each "iteration", but I'm not sure it's worth such a long parameter label. Maybe `sequence(state:update:)`? On Thu, May 19, 2016 at 8:46 PM, Patrick Smith wrote: > Would `sequence(mutatingState:next:)` perhaps be

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

Would `sequence(mutatingState:next:)` perhaps be clearer? > On 20 May 2016, at 10:37 AM, Trent Nadeau via swift-evolution > wrote: > > Ah, yes. I apologize. The fact that state is inout, and the same instance is > always passed in confused me. Thanks for the

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

on Thu May 19 2016, Jacob Bandes-Storch wrote: > Hm. That might conflict with: > http://thread.gmane.org/gmane.comp.lang.swift.evolution/17575 That doesn't bother me, personally. > On Thu, May 19, 2016 at 4:02 PM, Austin Zheng via swift-evolution < >

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

Ah, yes. I apologize. The fact that state is inout, and the same instance is always passed in confused me. Thanks for the correction. On Thu, May 19, 2016 at 7:46 PM, Brent Royal-Gordon wrote: > > Also note that there's a typo in the second example: > > > > for view in

Re: [swift-evolution] ADC Swift Blog

Thank you, Patrick. I’ve got point! Have a good weekend you too! Sincerely, Pavel Kapinos. > On May 19, 2016, at 4:41 PM, Patrick Smith wrote: > > There’s some new posts, they’re just not listed: > >

Re: [swift-evolution] ADC Swift Blog

Although I might welcome a separate bikeshedding mailing list, I have a feeling it would just wind up being CC’d rather than being the sole target of said conversation. -DW > On May 19, 2016, at 5:41 PM, Patrick Smith via swift-evolution > wrote: > > There’s some

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

On Thu, May 19, 2016, at 04:20 PM, Trent Nadeau via swift-evolution wrote: > Also note that there's a typo in the second example: > > for view in sequence(initial: someView, next: { $.superview }) { // > someView, someView.superview, someView.superview.superview, ... } > > should be: > > for view

Re: [swift-evolution] ADC Swift Blog

There’s some new posts, they’re just not listed: https://developer.apple.com/swift/blog/introducing-the-swift-bikeshedding-mailing-list https://developer.apple.com/swift/blog/virtual-reality-playgrounds-the-next-paradigm

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

Hm. That might conflict with: http://thread.gmane.org/gmane.comp.lang.swift.evolution/17575 On Thu, May 19, 2016 at 4:02 PM, Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote: > Excellent. Having one canonical, unambiguous way to get the string > representation should make

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

> * What is your evaluation of the proposal? This is an important and positive addition to the standard library. It allows us to quickly build ad-hoc sequences and, combined with `prefix(while:)`, easily simulates most of what the C-style `for` loop could do. I can easily imagine using

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

* What is your evaluation of the proposal? +1. I've used unfold/iterate functions in Haskell and Clojure, and they are very useful. * Is the problem being addressed significant enough to warrant a change to Swift? Yes. * Does this proposal fit well with the feel and

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

> On May 14, 2016, at 22:16, 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

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

Hello Swift community, The review of "SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib" begins now and runs through May 23. This is a refinement of part of SE-0045. The proposal is available here:

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

on Tue May 10 2016, Nate Cook wrote: > I've needed these in the past and used them in other languages—any feedback > on this idea? > > - > > Add

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

Sent from my iPad > On May 19, 2016, at 4:07 PM, Антон Жилин wrote: > > OK, question 2 closed, we do need unlimited relationships. > Some critique to Brent's options: > 1. No separators, with multiple relations it becomes unobvious, which > comparison corresponds to

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I agree that it shouldn't be mandatory, but voluntary, even though I do not support it. E.g. looking at git diffs will always be cleared with self. - there's not syntax highlighting there. What I don't understand is why can't this be an option. There are two camps, each advocating either

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Hi Brandon, Thank you for the good question! We humans have been writing and reading software for a long time now. There are some words and keywords which stand out form the rest to mean something **well know** and one of them is acronyms. It is a habit and it works quite great in Cocoa in

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

> I managed to confuse at least two people! I've stated it in the grammar, but > forgot to give an example: > > ===begin=== > Multiple precedence relationships can be stated for a single precedence > group. Example: > ```swift > precedencegroup A { } > precedencegroup C { } > precedencegroup B

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Hi Charles, Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation

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

> On May 19, 2016, at 3:07 PM, Антон Жилин via swift-evolution > wrote: > > Thanks Brent, > > I managed to confuse at least two people! I've stated it in the grammar, but > forgot to give an example: > > ===begin=== > Multiple precedence relationships can be

[swift-evolution] ADC Swift Blog

Hi, I think Apple Developer Connections doesn’t advertise well what is going on with Swift 3 development, for example Swift blog on ADC is stalled from February. Come on people, let others know that Swift 3 is a big deal and urge others to read all its proposals because they shape up quite

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life. Sent from my iPhone > On May 19, 2016, at 11:56 AM, Pavel Kapinos via swift-evolution >

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

Thanks Brent, I managed to confuse at least two people! I've stated it in the grammar, but forgot to give an example: ===begin=== Multiple precedence relationships can be stated for a single precedence group. Example: ```swift precedencegroup A { } precedencegroup C { } precedencegroup B {

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 19, 2016, at 2:15 PM, Michael Peternell via swift-evolution > wrote: > > The problem that SE-0009 tries to solve is that when looking at a line in > isolation, like > >print(foo) > > there is no way to tell wether foo is an iVar, a local var or a

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Is the status quo in this honey moon phase better? Sent from my iPhone > On 19 May 2016, at 19:12, Sean Heber via swift-evolution > wrote: > > I think it is too easy to just add warnings for warts and call it a day. > These problems, IMO, should be addressed

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Well, SE-0009 is not related to shadowing, is it? I think it is something completely different. The problem that SE-0009 tries to solve is that when looking at a line in isolation, like print(foo) there is no way to tell wether foo is an iVar, a local var or a parameter. This can happen

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Hi Brent, Thank you for you encouragement! Please join in to support it **now**! Cheers, Pavel. > On May 19, 2016, at 11:53 AM, Brent Royal-Gordon > wrote: > >> SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in >> Proposed Solution # 6

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

> SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in > Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed > values whenever they are imported” with an example of URLHandler property > becoming urlHandler. Being long time Cocoa developer, I object

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.

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Hi, Exactly! The reading habits increase comprehension and speed up things. That’s why I applaud here to those who developed Cocoa API over the years keeping it consistent and **easy** and **fast** to read and write. Again, please keep the good and proven things from Cocoa in Objective-C!

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Oh, in this case IMO warning for 'self.' will never be introduced, it's clear. And as I understand, no support in community for warning for shadowing. OK, so as I understand, the only solution here - tools like SwiftLint and plugins to xcode. Btw, regarding 'similar to the override keyword',

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I think it is too easy to just add warnings for warts and call it a day. These problems, IMO, should be addressed somehow eventually - but not with a warning. Either Swift decides these situations are errors and refuses to enable them at all, or the constructs involved should be carefully

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

I don't remember the exact paper I read, but e.g. on Wikipedia - https://en.wikipedia.org/wiki/Word_recognition - but googling for "reading by shapes" etc. turns out a lot of various articles. But I see it myself - urlHandler - I immediately see Handler, but have to read into it letter by

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] Proposal SE-0009 Reconsideration

And... is this all OK? No one think this is a broken design? So, in addition to the example with getInt() (when no method declaration exists in protocol itself, but just in extension and in type), we have this: protocol A { func f() func x() } extension A { func x()

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Sure, though not all apps are designed to be localized and can serve for internal purposes or simply the developer can say that he's supporting English (or another language) only - that's entirely his decision. Also some strings, do not get localized. For example some kinds of string-ified

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I believe the Swift Team has previously stated they do not want opt-in warnings defining alternate swift ‘grammars’. I don’t believe there are any existing -W flags for the compiler, for instance. If there is shadowing warning added, I’m of the opinion it should work similar to the override

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Forget me if I'm wrong, but wouldn't localization requirements make string interpolation unsuitable for user facing strings anyway? (I remember localization being discussed previously, but don't recall it turning into a proposal) - David Sent from my iPhone > On 19 May 2016, at 19:06,

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Oh, cool! This is exactly the same code I was asking the community to comment out if this is wanted/expected behavior. Unfortunately no reply was given. This is why I suggested a warning if type's method has the same name as such protocol extension method in my current thread "[Pitch] Requiring

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Do you have a source for this? While I bet there is research showing that acronyms on their own are easier to read in all caps, does it talk about when it is joined with other words such as urlHandler? And like I said, just because ObjC devs are used to it is probably not a good enough

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

I strongly prefer that things like properties and variables, even if they start with an acronym or initialism, start lowercase. When writing Objective-C, if I have a property or variable named just "url", I always debate whether I should call it "URL" or "url". This will become even trickier once

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 18.05.2016 22:43, Krystof Vasa wrote: I agree that shadowing variables is not a good idea, but I stand by my point that it's potentially dangerous and error-prone to allow accessing instance variables without `self`. Could we all agree that we need these options: 1. option to turn on

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I'd prefer to raise warning for any shadowing, and so, in case of `if let value = value` we'll have a warning: in discussions about 'if let! value' construction proposal there was many opinions that 'if let v = v' is a bad style and you should avoid to do this and improve your code to not do

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

Aside from ObjC developers being used to this, psychology of reading tells us that people read by shapes of the words - they are used to seeing abbreviations in capital letters - from this point, it's better readable. > On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution >

Re: [swift-evolution] [Pitch] Requiring special keyword to mark protocol implementation methods

Leonardo, Based on the discussion for similar subject, I feel like community and core team does not support the idea of more verbose decoration of protocol implementation in type. So, my initial proposal is trying to add the minimum of changes to the current state to increase the level of

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

Jeremy, inline: By the way, in the future directions version of the BitwiseShift group we > have > members(<<, >>) > Is that a typo? Thanks, will try to fix it. Also, just to confirm that my understanding of how this will work is > correct, the proposal seems to suggest that future

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

On Thu, May 19, 2016, at 02:33 AM, Jeremy Pereira via swift-evolution wrote: > > > On 17 May 2016, at 23:45, Eric Wing via swift-evolution > > wrote: > > > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > > makes my life harder, but on the

Re: [swift-evolution] RFC: didset and willset

> On 18 May 2016, at 21:53, Erica Sadun via swift-evolution > wrote: > > Just some context: > > "We have a few conjoined keywords already (typealias, associatedtype, > fallthrough). In the discussion about these terms, we decided that these > read best when all

Re: [swift-evolution] Proposal SE-0009 Reconsideration

In addition to what has already been posted: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://medium.com/ios-os-x-development/swift-protocol-extension-method-dispatch-6a6bf270ba94#.14j0qq1i3 (even more complete summary of previous research in this issue)

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 19, 2016, at 3:14 AM, L. Mihalkovic > wrote: > > It strikes me that in a sense, the proposed StaticSelf is basically what '_' > does > > By specifying StaticSelf we are trying to tell the compiler to ignore what is > going on that

Re: [swift-evolution] Proposal SE-0009 Reconsideration

See this example that demonstrates how it's pretty much unusable (IMHO), since whenever you refer to the instance as to the protocol, the default implementation gets invoked: protocol MyProtocol { } extension MyProtocol { func getInt() -> Int { return 0 } }

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 19.05.2016 0:01, Michael Peternell wrote: Not Fun To Debug bits (similar to the dispatching rules of protocol extensions default methods). There are dispatching rules of protocol extension default methods? I thought the methods are selected randomly... just kidding - [offtopic] Could you

Re: [swift-evolution] Proposal SE-0009 Reconsideration

On 19.05.2016 0:09, Krystof Vasa via swift-evolution wrote: Yes, of course. But if you mark shadowing as error/warning, you need to update dozens if not hundreds of places in your projects since most default argument names in UITableViewController shadow the tableView instance variable. I

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

> On 18 May 2016, at 04:30, Chris Lattner via swift-evolution > wrote: > > > * What is your evaluation of the proposal? +1. A major improvement over the current system. I’m fine with the suggested syntax in general. I’ll be using it rarely enough that it

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Strong +1 for the (at least) warning in case of optional in string interpolation. Actually I think `Optional(something)` is a form of text representation for *debugging only*, not for 'production'. It is clear, that by default we need text representation for 'production', so it is logical for

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

> Is completing the generic system fundamental or not? I’d say it is vastly > more fundamental than removing C style for loops, wouldn’t you? Oh, come on. Removing the C-style for loop is not what took up time in this release cycle. What took up time is the API guidelines, the new collection

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

> On 17 May 2016, at 23:45, Eric Wing via swift-evolution > wrote: > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > makes my life harder, but on the flip-side, I don’t want to be stuck > with yet another broken language and ABI. I want this

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

> * What is your evaluation of the proposal? The review is technically over, but I don't believe a decision has been announced yet, so... I am generally in favor, but I have a serious concern about the readability of certain conversions with this change. To wit, conversions like these:

Re: [swift-evolution] [Review] SE-0050: Decoupling Floating Point Strides from Generic Implementations

> * What is your evaluation of the proposal? +1. It might not be pretty, but it is an improvement. The Proposed Solution doesn't compile with development snapshot 05-09 (SE-0067 hasn't landed yet, IIRC). I hacked it to get it to compile, and tested it with two problematic cases: Test #1: let

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

> On 17 May 2016, at 14:38, Rod Brown wrote: > > While on the face of it, you are correct, the goals have changed > dramatically, I think you are being unfair. The goals changed dramatically last week. It’s there in the git history. Last week was *after* the first

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I think displaying a warning instead of deprecation would suffice. A down vote for deprecation. On 19 May 2016, 4:06 PM +0800, Patrick Smith via swift-evolution, wrote: > Yes, I think I agree this should show a warning, and require you to > explicitly state that you

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

It strikes me that in a sense, the proposed StaticSelf is basically what '_' does By specifying StaticSelf we are trying to tell the compiler to ignore what is going on that that precise location to revert to something expressed 'earlier'. This is somehwat anologous to what we do when we use

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Yes, I think I agree this should show a warning, and require you to explicitly state that you are happy dealing with an optional. Possibly you would have to add a ? suffix to make it explicit: "http://apple.com\(originalURL.path?)/help” This would be compatible with

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

I assume you meant to use Any and not protocol above. No, I was wondering why Any> would create a warning whereas protocol does not today. They can all be interpreted, but: - they provide multiple ways of expressing the same concept - the additional uses of Any detract from code

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

Forbidding redundant use of protocol<...>/Any<...> would be a great follow-up proposal. Mercifully, there are few interdependencies between the two proposals - you could conceivably propose it even if if Any<...> were rejected, and just have it apply to protocol<...>. Austin > On May 19,

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

> On May 19, 2016, at 1:11 AM, Adrian Zubarev via swift-evolution > wrote: > > Austin do we really need this 3rd proposal? This makes my original one really > a waste of time. I was trying to solve https://openradar.appspot.com/20990743 >

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Consider the following example: let originalURL: NSURL = NSURL(string: "http://apple.com/iphone;)! let newURL = NSURL(string: "http://apple.com\(originalURL.path)/help") What's the newURL? Nil, because it was being inited with http://apple.comOptional(/iphone)/help Since the path property is

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

Sorry, you're right about the timeframe. The timeframe I was looking at was for the DP release, not the final release. What I was thinking of was Joe Groff's comment in the other thread: "I think any discussion of extending existentials has to be considered out of scope for Swift 3, though, so

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Actually, I just noticed the comment about never wanting to show an optional value. That is a fair point, and worthy of consideration. I'm happy as long as there is no surprising behavior going on :) On Thu, May 19, 2016 at 12:28 AM Dan Appel wrote: > You know what's

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

You know what's worse than seeing "Optional(my string value)" in a label? Seeing "nil". When the optional is there, it is made clear to the developer that the string they are showing *can be nil*. However, if you hide that from the users you are less likely to unwrap that optional and hence more

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

Is it really in a month? Who said that? Chris told everyone that until August we can still talk about changes for Swift 3. The evolution repository says Swift 3 will drop late this year not mid. But it’s the core team to decide which proposals they would prefer. This one would be way easier to

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

If lazy becomes @lazy, shouldn't dynamic become @dynamic as well? They both don't change the type as argued in the proposal, it only changes the way the value is accessed. Krystof > On May 19, 2016, at 4:19 AM, Jose Cheyo Jimenez via swift-evolution > wrote: > >

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Making string interpolation reject just optional (at compile time) when it doesn’t reject any other type sounds tricky to express. What if instead Optional just didn’t decorate the wrapped value, outputting either the inner value or “nil” in these cases? The debugDescription could remain

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

> On May 19, 2016, at 12:20 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > I commented earlier, but didn't actually review. > > I'm in favor of this change *if* we are very sure that the syntax will not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

> * What is your evaluation of the proposal? I commented earlier, but didn't actually review. I'm in favor of this change *if* we are very sure that the syntax will not change again, even if `lazy` is reimplemented as a property behavior. If we are *not* sure of this, however, then I

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

I've come to the conclusion that the best course of action is to propose this syntax-only change for Swift 3, and then advance the generalized existential proposal after Swift 3 ships. You can ask the reviewers to consider your proposal instead of this one, but given that the Swift 3 release

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve https://openradar.appspot.com/20990743  with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes. To that

Re: [swift-evolution] RFC: didset and willset

I don't see a cleaner solution for observing value change for a property on superclass: class MyView: UIView { override var bounds: CGRect { didSet { self._clearCachedValues() } } } Without didSet, you need to do this:

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code. To that end, I’d suggest Any<>,Any, and Any all cause warnings. -DW > On May 19, 2016, at 12:43 AM, Austin Zheng

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form. Austin > On May 18, 2016, at 11:33 PM, Colin Barrett > wrote: > > There's no need for this, that's what I was trying to

Re: [swift-evolution] RFC: didset and willset

Because some posts explicitly stated the willSet/didSet-functionality should be kept (and I mentioned the option of discarding them): My statement had the same background as Brent's — I expect there will be a "cleaner" and more versatile replacement in the future, so "don't fix it if it isn't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0050: Decoupling Floating Point Strides from Generic Implementations

> * What is your evaluation of the proposal? No mistake: this is a pretty ugly solution to the problem. However, it *is* a problem that badly needs solving, and all the other solutions (like "always use the float logic and let the optimizer fix it up into integer logic") are far worse.

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any are just a built in type and normal application of generic arguments (to a built in

  1   2   >