Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 29, 2016, at 1:23 PM, Haravikk via swift-evolution > wrote: > > This is definitely something I’m hoping to see as well, alongside more > intelligent handling of the is keyword, as currently Swift doesn’t handle the > following either: > > if foo is

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 30, 2016, at 5:42 PM, Rod Brown wrote: > > Re-sent for Swift Evolution. Response at end. > > On 1 May 2016, at 6:31 AM, David Sweeris > wrote: >>> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution

Re: [swift-evolution] multi-line string literals.

In my opinion, one problem is that we don’t have a reference to a laundry or wish list of what features we would like around string literals in the language. Without evaluating a proposal against all of those features (moves forward, doesn’t impact, creates later issues for) it is hard to

Re: [swift-evolution] Extending init checks for property initialization

This is probably the best pattern to deal with this, since there are a number of ugly problems to deal with if passing an incomplete object around. initializers exist with a lot of special case rules around self because they are reusing the term for something that is actually not yet self, but

Re: [swift-evolution] multi-line string literals.

> Second, this proposal should explain why it's reinventing the wheel > instead of standardizing existing, very successful, prior art. Answer > the question: “what compelling advantages does this syntax have over > Python's?” Sure. First of all, I will admit up front that I have not written

Re: [swift-evolution] multi-line string literals.

on Thu Apr 28 2016, Brent Royal-Gordon wrote: > Awesome. Some specific suggestions below, but feel free to iterate in a > pull > request if you prefer that. > > I've adopted these suggestions in some form, though I also ended up rewriting > the explanation of

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, "Ted F.A. van Gaalen via swift-evolution" wrote: > @Dave also > what do you think about this? > I am trying to avoid the conclusion that most Swift-evolution > participants are very much FP biased. is this the case? I don't believe so. >

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

on Fri Apr 29 2016, Matthew Judge wrote: > I believe the following idea was brought up on the list the last time > this topic came up, but I think it has a number of advantages and gets > rid of the need for a 'required' keyword completely. I have > reservations on

Re: [swift-evolution] Protocol non-conformance clause

> On Apr 29, 2016, at 3:18 PM, Thorsten Seitz wrote: > > >> Am 29.04.2016 um 19:51 schrieb Xiaodi Wu > >: >> >> Yes, certainly this works today. The motivation for Erica's question is that >> this would not work without

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 30, 2016, at 10:19 AM, T.J. Usiyan via swift-evolution > wrote: > > I agree that a keyword indicating intent would be nice, but I can't get > behind override if what you're doing is providing your own implementation. I > understand that we are trying to

Re: [swift-evolution] Auto Unwrapping Of Optionals

Re-sent for Swift Evolution. Response at end. On 1 May 2016, at 6:31 AM, David Sweeris wrote: >> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution >> wrote: >> >> I think this specific proposal asking for compiler magic to auto-unwrap

Re: [swift-evolution] multi-line string literals.

Hi Brent, @Dave - Hi Dave, please see at the end of this email. Thanks for your energetic reply, Brent. First of all, I think there is a place in Swift for “your” and “mine” proposing solutions together. I will reply further inline -> > On 30.04.2016, at 09:43, Brent Royal-Gordon

[swift-evolution] multi-line string literals proposal

I've written up a proposal for multi-line string literals. Before proposing it officially, I would like to get some informal feedback. How can I propose it officially? Do I have to convert it to Markdown? I have no idea how to create a Markdown version of this, with all the quotes and funny

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On 29 Apr 2016, at 15:37, Tod Cunningham via swift-evolution > wrote: > > This concept of Auto Unwrapping of Optionals is similar to Implicitly > Unwrapped Optionals, but is only applied when the compiler knows it is safe > to do so. > > Take the following

Re: [swift-evolution] SE-0045 Add scan, prefix(while:), drop(while:), and unfold to the stdlib

Precedent suggests that they should be named either drop/take, or possibly skip/take. But Swift chose drop/prefix already (we have dropFirst and dropLast already in the stdlib), which is why this proposal is following the same terminology. -Kevin On Sat, Apr 30, 2016, at 02:29 AM, William

Re: [swift-evolution] Auto Unwrapping Of Optionals

That would be handy Sent from Supmenow.com On Sat, Apr 30, 2016 at 1:31 PM -0700, "David Sweeris via swift-evolution" wrote: On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution wrote: I think this specific proposal

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution > wrote: > > I think this specific proposal asking for compiler magic to auto-unwrap > invisibly and only in very limited cases, as this proposal suggests, ends up > breaking a lot more than it fixes. I

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

Is this is a plist like construct, couldn’t it simply be declared as [NSString: AnyObject] ? As we are talking about removing implicit cast, forcing the user to use NSString explicitly for API that need a NSDictionary is probably not a problem ? let userInfo: [NSString: AnyObject] = [

Re: [swift-evolution] multi-line string literals.

> On Apr 30, 2016, at 11:54 AM, Tyler Fleming Cloutier via swift-evolution > wrote: > > >> On Apr 28, 2016, at 2:56 PM, Brent Royal-Gordon via swift-evolution >> > wrote: >> >>> Awesome. Some specific

Re: [swift-evolution] multi-line string literals.

> On Apr 28, 2016, at 2:56 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Awesome. Some specific suggestions below, but feel free to iterate in a >> pull request if you prefer that. > > I've adopted these suggestions in some form, though I also ended up

Re: [swift-evolution] multi-line string literals.

> On Apr 28, 2016, at 2:56 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Awesome. Some specific suggestions below, but feel free to iterate in a >> pull request if you prefer that. > > I've adopted these suggestions in some form, though I also ended up

Re: [swift-evolution] Extending init checks for property initialization

'defer' in this example means something different than 'defer' as used in Swift today. I would expect a 'defer init()' to be called immediately before the main initializer goes out of scope, like how a defer block works today, but this defer init() must be called when the main initializer first

Re: [swift-evolution] Extending init checks for property initialization

Agreed. The static option is definitely better. But I think a deferred option would be that much more elegant. > On Apr 30, 2016, at 11:30 AM, Basem Emara wrote: > > Hey Hooman, that’s very elegant. I didn’t think of it like that and will > definitely use, thx! > >

Re: [swift-evolution] Extending init checks for property initialization

Hey Hooman, that’s very elegant. I didn’t think of it like that and will definitely use, thx! Though wouldn’t “defer init()” take it a step further: 1) reduce redundant boilerplate 2) prevent forgetting/bugs and 3) smaller memory allocation footprint? It also fits well with the existing Swift

Re: [swift-evolution] Extending init checks for property initialization

Besides the ages old designated initializer pattern that is already suggested (having a few designated initializers and a bunch of convenience initializers), this is how I have been dealing with this since Swift 1.0: import UIKit import AVFoundation class SomeViewController: UIViewController {

Re: [swift-evolution] multi-line string literals.

Same here. IMHO, there needs to be a version of multi line strings that's doesn't require to prefix a token on each line. > On 30 Apr 2016, at 09:20, Daniel Phillips via swift-evolution > wrote: > > Sorry for any extra noise here. I've read the 58 emails in this

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I agree that a keyword indicating intent would be nice, but I can't get behind override if what you're doing is providing your own implementation. I understand that we are trying to avoid adding keywords but could `implement` or a synonym work? If you override something that your superclass

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

On 4/29/16 21:32, Jordan Rose via swift-evolution wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md] > > I’m a little concerned about the affect this has on “plist literals”. > Specifically, I can no longer

Re: [swift-evolution] [Bug?] Reference types and mutating methods

The problem here seems to be with using the default implementation provided. If you override `append` in ObservedArray, the compiler allows it. That seems 'safe' but odd at first. I wouldn't *want* to implement every mutating method, but that is the current solution. I haven't puzzled out the

Re: [swift-evolution] Auto Unwrapping Of Optionals

I definitely agree there are difficulties with working with nullability and structs. Interesting perspective on how to deal with that. I'd be interested in what others think of your inout type idea. I think this specific proposal asking for compiler magic to auto-unwrap invisibly and only in

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I like your example because it focusses on the scenarios I often have to deal with: namely to inherit working code that is lacking flexibility and/or abstraction (extensibility). Then I have to find convoluted ways to retrofit some abstractions that do not alter the original code, but let me

[swift-evolution] SE-0045 Add scan, prefix(while:), drop(while:), and unfold to the stdlib

func drop(@noescape while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence func prefix(@noescape while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence Now I may just be a simple country hyper-chicken, but so I don’t know if

Re: [swift-evolution] Auto Unwrapping Of Optionals

Wouldn't calling the NSDate constructor escape the context ? Sent from Supmenow.com On Fri, Apr 29, 2016 at 1:47 PM -0700, "Tod Cunningham via swift-evolution" wrote: Adrian, excellent example of a challenging case. I would say that when calling any

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

> On Apr 29, 2016, at 5:10 PM, Jordan Rose wrote: > >> >> On Apr 28, 2016, at 17:22, Andrew Trick via swift-evolution >> > wrote: >> >> >>> On Apr 28, 2016, at 11:10 AM, Chris Lattner

Re: [swift-evolution] multi-line string literals.

> Example 1. The \@ operator: > >// 1. multi-line string literal with data lines as is. > // It loads each line (part) up to and including the > source-file-line- end: > // you can use all available characters without problems, > // even \\ and \@ thus

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 28, 2016, at 8:09 PM, Erica Sadun via swift-evolution > wrote: > > Sorry, that's not my question, which doesn't involve protocols I don't own. > Let me restate. Given three types I don't own as follows: > > ``` > struct A : Frobnicate { > override

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution > wrote: > > I agree that it's a pain to have to unwrap after this, but this proposal > worries me somewhat. > > I don't think we can safely guarantee that the value is non-null outside a > very limited

Re: [swift-evolution] multi-line string literals.

Sorry for any extra noise here. I've read the 58 emails in this thread and I just wanted to chime in my support for Dave here. I think a multiline string literal implementation along the lines of Python is a no brainer. In particular when I've needed and wanted multiline string literals it

Re: [swift-evolution] multi-line string literals.

let whyOwhy = _"\ !!Can't understand what improvements it truly delivers !!It basically removes a handful of characters !!It works today !!But I don't see it as a likable foundations for adding in future enhancements !!\ !!I don't envy the

Re: [swift-evolution] multi-line string literals.

> I think we should definitely propose the items in "Absolutely Necessary" and > consider proposing the ones in "Really Nice To Have" for Swift 3. I think we > should definitely do the "Really Nice To Have, But We Can't" item in Swift 4. > I think we should revisit and consider the others in