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

On the downside: This is absolutely true. All of those conversions would be the first up against the well when the revolution comes. On the upside: I imagine a compiler warning could be pretty reasonably whipped up to detect these, and after the dust cleared, we’d be able to just try

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

> On May 6, 2016, at 9:19 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > >> >> On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Fri May 06 2016, Matthew

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

> On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri May 06 2016, Matthew Johnson > wrote: > >>On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution >>

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

On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote: > > on Fri May 06 2016, Kevin Ballard wrote: > > > On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: > >> > >> on Fri May 06 2016, Kevin Ballard

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

Agreed, but I'm sure lots of user code depends on it (e.g. when extracting numeric values from property lists). If it stopped working, wouldn't these "as?" casts silently start returning nil where they didn't before? On Fri, May 6, 2016 at 8:20 PM Charles Srstka wrote:

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

* What is your evaluation of the proposal? +1 I agree with others that there are opportunities to generalise this proposal. It would be pretty magical if it could be applied to escaping closures, less magical if that's just adding a runtime assertion. It would also be much more flexible if it

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

> On May 6, 2016, at 19:48, Dave Abrahams via swift-evolution > wrote: > > Sorry, this is the first mention I can find in the whole thread, honest. > Oh, it was a different thread. Joe describes it as a protocol for > “types that represent fully self-contained

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

> On May 6, 2016, at 3:15 PM, Joe Groff via swift-evolution > wrote: > >> On May 6, 2016, at 12:21 PM, Jacob Bandes-Storch via swift-evolution >> > wrote: >> >> Does this affect the ability to use "x as?

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution > wrote: > > I formerly posted a less-fleshed-out version of this in the “Reducing > bridging magic” thread, but I thought this might warrant its own pitch. What > do you all think? > > MOTIVATION: >

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Replies inline: On Sat, May 7, 2016 at 12:37 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri May 06 2016, Andrew Bennett wrote: > > > Hi Dave, > > > > Sorry, Dave, sending a second time as I forgot to Reply-All. > > > > I agree,

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

on Fri May 06 2016, Andrew Bennett wrote: > Hi Dave, > > Sorry, Dave, sending a second time as I forgot to Reply-All. > > I agree, this proposal doesn't allow multiple closures where only one of them > should be run, and it should only be run once. I personally don't

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Hi Joe, Would I still be able to cast an AnyObject to a String or Array etc? I am thinking about working with JSON files and using the Apple JSON Parser. Thanks > On May 3, 2016, at 4:50 PM, Joe Groff via swift-evolution > wrote: > > Thanks everyone for the

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Hi Dave, Sorry, Dave, sending a second time as I forgot to Reply-All. I agree, this proposal doesn't allow multiple closures where only one of them should be run, and it should only be run once. I personally don't think lacking that functionality is worth blocking this proposal for, another

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

On Fri, May 6, 2016, at 06:15 PM, Dave Abrahams via swift-evolution wrote: > > on Fri May 06 2016, Matthew Johnson wrote: > > >> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution > >> wrote: > >> > >> > >> on Fri May 06 2016,

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

On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: > > on Fri May 06 2016, Kevin Ballard wrote: > > > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: > >> On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote: > >> >

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

on Fri May 06 2016, Matthew Johnson wrote: > On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu May 05 2016, Matthew Johnson wrote: > > On May 5, 2016, at 10:02 PM, Dave Abrahams >

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Agreed. I think you bring up points that articulate well my issues with this proposal. > On 7 May 2016, at 10:31 AM, Greg Parker via swift-evolution > wrote: > > >> On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution >> wrote:

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

> On May 6, 2016, at 8:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri May 06 2016, Matthew Johnson > wrote: > >>> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution >>>

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

on Fri May 06 2016, Erica Sadun wrote: > On May 6, 2016, at 6:27 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu May 05 2016, Erica Sadun > wrote: > > On May 4, 2016, at 5:50 PM, Chris

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

on Fri May 06 2016, Matthew Johnson wrote: >> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri May 06 2016, Cole Campbell wrote: >> >>> I don't know if it's considered

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

On May 6, 2016, at 6:00 PM, Erica Sadun via swift-evolution wrote: > That aside, the prevailing sentiment is to rename reduce to `fold` and > partner it with `unfold`. > (I personally prefer Chris's `sequence` because I think it better reflects > how more Swift users

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

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: >> On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote: >> > >> > on Wed May 04 2016, Chris Lattner wrote: >> > >> > >

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

> On May 6, 2016, at 8:54 AM, David Hart wrote: > > Chris, as many people seem to be currently in favour of renaming reduce to > fold to support unfold, should be write a proposal, or can the modification > be accepted with less formality? We would *definitely* have to

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

On May 6, 2016, at 6:27 PM, Dave Abrahams via swift-evolution wrote: > > > on Thu May 05 2016, Erica Sadun > wrote: > >> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Idea: Allow/require "let" in property setter name declarations

On May 6, 2016, at 4:09 AM, Ian Partridge via swift-evolution wrote: > Currently, the syntax for explicitly naming property setters is: > > set(newPerimeter) { // declares newPerimeter parameter, "let" not allowed > sideLength = newPerimeter / 4.0 > } >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

on Wed May 04 2016, Colin Barrett wrote: >> Swift numeric types all currently have a family of conversion > initializers. In many use cases they leave a lot to be > desired. Initializing an integer type with a floating point value will > truncate any fractional

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

on Thu May 05 2016, Matthew Johnson wrote: > On May 5, 2016, at 10:02 PM, Dave Abrahams > wrote: > > on Thu May 05 2016, Matthew Johnson wrote: > > On May 5, 2016, at 4:59 PM, Dave Abrahams >

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

> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri May 06 2016, Cole Campbell wrote: > >> I don't know if it's considered too late at this point to rename 'reduce', >> but >> I'll add an enthusiastic

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

on Fri May 06 2016, Cole Campbell wrote: > I don't know if it's considered too late at this point to rename 'reduce', but > I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. > 'Fold' > is just as obvious a name as 'reduce', IMO (actually I

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

On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote: > On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote: > > > > on Wed May 04 2016, Chris Lattner wrote: > > > > > Proposal link: > > >

[swift-evolution] [Proposal] Memorization for running function only once

Hi, I propose* "*memorization" or "memo" keyword for a function that allows to run only once through out the lifecycle in Swift 3. Repeatedly execute the function will only return the same result without having to rerun the function everytime. memo func hello(fname: String, lname: String) {

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

On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote: > > on Wed May 04 2016, Chris Lattner wrote: > > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md > > > > Hello Swift

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

> On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0073: Marking closures as executing exactly once" begins > now and runs through May 9. The proposal is available here: > > >

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

on Thu May 05 2016, David Hart wrote: > If we are discussing naming changes to reduce, here's my personal opinion: > > * When I first encountered it, I understood exactly what it did because I knew > that term of art. If it was named sequence, I would have been >

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

on Thu May 05 2016, Erica Sadun wrote: > On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

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

on Wed May 04 2016, Chris Lattner wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md > > Hello Swift Community, > > The review of SE-0045: "Add scan, prefix(while:), drop(while:), and > unfold to

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? I believe so. * Does this proposal fit well with the feel and direction of Swift? Yes * If you have used other languages or libraries with a

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

On Fri, May 6, 2016, at 02:23 PM, Dave Abrahams via swift-evolution wrote: > > on Fri May 06 2016, Kevin Ballard wrote: > > > One idea that came out of the core team discussion was something like: > > > > sequence(from: 0) { $0 += 42 } > > > > Since it

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Fri May 06 2016, Nate Cook wrote: >> On May 6, 2016, at 4:20 PM, Dave Abrahams via swift-evolution >> wrote: >> >>> on Fri May 06 2016, Nate Cook wrote: >>> >>>How can you reverse a variable-length collection with a fixed number of >>>iterations? Are

Re: [swift-evolution] Dropping NS Prefix in Foundation

I am definitely +1 to this proposal direction I was in the crowd thinking "don't drop the NS on types that should be value types" but I think you make fair points that there can be planned optimizations in the future, and we should focus on getting a good set of naming rules in place. You make

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 6, 2016, at 4:20 PM, Dave Abrahams via swift-evolution > wrote: > >> on Fri May 06 2016, Nate Cook wrote: >> >>How can you reverse a variable-length collection with a fixed number of >>iterations? Are you talking about loop unrolling in the

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and myself. on Tue May 03 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0074: Implementation of Binary Search functions" > begins now and runs through May 9. The proposal

Re: [swift-evolution] Dropping NS Prefix in Foundation

Hi David, > On May 6, 2016, at 2:56 PM, David Waite wrote: > > -1 On the group as-is. I do not believe all of these classes have the > behavior that would be expected if ‘foundation’ were a from-scratch > foundational library for Swift (as it exists on non Apple

Re: [swift-evolution] Dropping NS Prefix in Foundation

-1 On the group as-is. I do not believe all of these classes have the behavior that would be expected if ‘foundation’ were a from-scratch foundational library for Swift (as it exists on non Apple platforms). This will lock Swift into an evolutionary path for these types going forward. There is

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

on Fri May 06 2016, Kevin Ballard wrote: > One idea that came out of the core team discussion was something like: > > sequence(from: 0) { $0 += 42 } > > Since it returns a sequence. > > It just occurred to me that, if we follow existing naming conventions,

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Fri May 06 2016, Nate Cook wrote: > How can you reverse a variable-length collection with a fixed number of > iterations? Are you talking about loop unrolling in the library? > > I mean looping count / 2 times instead of looping while lowIndex < > highIndex, Why do you think that

[swift-evolution] Dropping NS Prefix in Foundation

Hi everyone, Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). I’m back again with more information on another part of our plan to integrate Foundation API into Swift: dropping the NS prefix. When we originally proposed this as part of the API guidelines document

[swift-evolution] [Proposal] Multiline string literals

Hi, I propose adding multiline string literals to Swift 3. I have written up a proposal as a Github Gist, here: https://gist.github.com/michaelpeternell/a4da4185de78808f4575a836c50debbd Can someone with write-access

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

on Tue May 03 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0073: Marking closures as executing exactly once" > begins now and runs through May 9. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

on Thu May 05 2016, Nate Cook wrote: > Thanks for the feedback, Dmitri , this all looks excellent! I'll work on > updating the proposal. > >> On May 5, 2016, at 6:13 PM, Dmitri Gribenko wrote: >> >> On Tue, May 3, 2016 at 8:57 PM, Chris Lattner

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

> On May 6, 2016, at 12:21 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Does this affect the ability to use "x as? Int" (and similar) when x is an > NSNumber? No, this only affects compile-time implicit conversions. I proposed changing the runtime

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

Does this affect the ability to use "x as? Int" (and similar) when x is an NSNumber? Jacob On Thu, May 5, 2016 at 9:50 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: >

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

> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon > wrote: > >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error. All lines

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

> On May 6, 2016, at 7:13 PM, L Mihalkovic wrote: > > As I (believe I) start to understand the parser, I somehow think that doing > something like the following would > not violate (not take too much risk) the current Lexer/Parser > be somewhat reasonable to

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

On Thu, May 5, 2016, at 01:39 PM, Chris Lattner via swift-evolution wrote: > >> On May 5, 2016, at 1:03 PM, Erica Sadun wrote: >> >> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution > evolut...@swift.org> wrote: >>> >>> Proposal link: >>>

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

Yes @Matthew, I did; my very first draft sought to change the default subscript method. However, there were some opinions against overriding the default *fail fast* behaviour as it could result in more bugs and in an overload to debug. It wasn't set in stone, so I think it's something that could

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

As I (believe I) start to understand the parser, I somehow think that doing something like the following would not violate (not take too much risk) the current Lexer/Parser be somewhat reasonable to implement address many of the reqs I read leave some infrastructure in the Lexer/Parser to add

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

> On May 6, 2016, at 9:42 AM, Stephen Canon wrote: > > >> On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution >>>

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

> On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution > wrote: > >> >> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution >> wrote: >> >> Currently, in order to conform to FloatLiteralConvertible you need to >>

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution > wrote: > > Currently, in order to conform to FloatLiteralConvertible you need to > implement > an initializer accepting a floatLiteral of the typealias: FloatLiteralType. > However, this

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

Did you consider making the safer, optional overload the "default" and just omit the label? Sent from my iPad > On May 6, 2016, at 10:23 AM, Luis Henrique B. Sousa via swift-evolution > wrote: > > "bounded" sounds good to me, but I don't know if "optional" is a

Re: [swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

On Fri, May 6, 2016 at 2:24 AM, Morten Bek Ditlevsen via swift-evolution wrote: > How does that sound? Is it completely irrational to allow the use of Strings > as > the intermediary representation of float literals? > I think that it makes good sense, since it allows

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

Chris, as many people seem to be currently in favour of renaming reduce to fold to support unfold, should be write a proposal, or can the modification be accepted with less formality? > On 06 May 2016, at 15:11, Matthew Johnson wrote: > > > > Sent from my iPad > >

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

Another way to address this might be by allowing property behaviors, a feature proposed in https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md to allow for factoring out property implementations, could also apply to `case` declarations. "Weak" and

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

"bounded" sounds good to me, but I don't know if "optional" is a good choice as it could be highlighted as a reserved keyword: https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design - Luis On Fri, Apr 29, 2016

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

> This means that the ChildGuardianship enum is no longer a real value type > with value semantics but a value type with partial reference semantics. That's already true of any enum that has an associated reference type. > On May 6, 2016, at 10:26 AM, Michael Peternell

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

> Am 06.05.2016 um 14:08 schrieb Marc Prud'hommeaux : > > >> I wonder if there is a practical use-case for this.. Is there? Just >> curious... > > Without getting too deep into the weeds of our specific data modal, I'll > summarize with "yes". If you need to mix classes with

Re: [swift-evolution] Making `.self` After `Type` Optional

> On May 6, 2016, at 12:04 AM, David Hart wrote: > > I understand why the alternative of changing the generic type parameter list > symbols was rejected, to be consistent with other C based languages, but I > don't understand why the following was rejected: > > •

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

Sent from my iPad > On May 6, 2016, at 1:29 AM, David Hart via swift-evolution > wrote: > > If we are discussing naming changes to reduce, here's my personal opinion: > > * When I first encountered it, I understood exactly what it did because I > knew that term

Re: [swift-evolution] Making `.self` After `Type` Optional

Definitely +1 to removing the .self requirement. Sent from my iPad > On May 5, 2016, at 11:34 PM, Joe Groff via swift-evolution > wrote: > > To keep progress going on this, I collected my thoughts from March's > discussion into a draft proposal: > >

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

Sent from my iPad On May 6, 2016, at 12:52 AM, Brent Royal-Gordon wrote: >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error.

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Am 05. Mai 2016 um 14:59 schrieb Matthew Johnson : Sent from my iPad On May 5, 2016, at 7:30 AM, Thorsten Seitz wrote: To me it reads as a constraint on R. Otherwise we would have to write `protocol R where … : Q where …, S where … { … }`

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

> I wonder if there is a practical use-case for this.. Is there? Just curious... Without getting too deep into the weeds of our specific data modal, I'll summarize with "yes". If you need to mix classes with enums and don't have the ability to declare the storage class of the variables, then

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

Sent from my iPad > On May 6, 2016, at 12:14 AM, L. Mihalkovic > wrote: > > Inline > > Regards > (From mobile) > >> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution >> wrote: >> >> On May 5, 2016, at 8:27 PM,

Re: [swift-evolution] Idea: Allow/require "let" in property setter name declarations

Actually a setter has more in common with a function, in which case the let implicit, the difference is that a setters type is also implicit. In fact, you don’t even need to specify a name in a setter at all, as the default is newValue and you can just use that. I’m more curious whether we

[swift-evolution] Idea: Allow/require "let" in property setter name declarations

Currently, the syntax for explicitly naming property setters is: class Square { var sideLength: Double = 0.0 var perimeter: Double { get { return sideLength * 4.0 } set(newPerimeter) { // declares newPerimeter parameter, "let" not allowed sideLength = newPerimeter /

Re: [swift-evolution] Making `.self` After `Type` Optional

Great I missed that change. Im fine with that change. :) I'd be happy to see `.self` being removed as well. -- Adrian Zubarev Am 6. Mai 2016 um 09:25:01, Pyry Jahkola (pyry.jahk...@iki.fi(mailto:pyry.jahk...@iki.fi)) schrieb: > > > > On 06 May 2016, at 10:19, Adrian Zubarev via

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

I would also be happy with ‘fold’/‘unfold’. The term of art argument applies to fold in the same way it does for ‘reduce’. Otherwise (if we stick with ‘reduce’) I find both ‘induce’ and ‘expand’ to be good names. I can also suggest ‘accumulate’. In each of these cases I prefer the local

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

+1 I’ve tried to write parameter lists like `acc, (valueA, valueB) in` in the past, expecting it to work like this > On 05 May 2016, at 20:22, Dennis Weissmann via swift-evolution > wrote: > > Following a short discussion with positive feedback on >

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

> Am 06.05.2016 um 05:24 schrieb Ricardo Parada : > > I think that is another one of the advantages of using the continuation > quotes. > > Sent from my iPhone > >> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution >> wrote: >>

[swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be aliased to String

Currently, in order to conform to FloatLiteralConvertible you need to implement an initializer accepting a floatLiteral of the typealias: FloatLiteralType. However, this typealias can only be Double, Float, Float80 and other built-in floating point types (to be honest, I do not know the exact

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

On Fri, May 6, 2016 at 12:53 AM, Nate Cook wrote: > That brings up the question of which protocol to add the requirement to? > Without a MutableBidirectionalProtocol (which we don't want, right?), we'd > need to add it to MutableCollection. While a mutating reverse() is

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 6, 2016, at 12:35 AM, Dmitri Gribenko wrote: > > On Thu, May 5, 2016 at 5:11 PM, Nate Cook > wrote: >> Thanks for the feedback, Dmitri , this all looks excellent! I'll work on >> updating the proposal. >> >>> On

Re: [swift-evolution] Referencing zero-parameter functions

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`. The updated proposal is also available on GitHub:

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

+1 I can’t wait for Swift 3 anymore. This ability would be great. Additionally what do you think about something like this? protocol DelegatableType {      protocol Delegate: class // enforced you to create a nested protocol      weak var delegate: Delegate? // or Self.Delegate? }  class A:

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

+1 from me as well. I have no problem with the function declaration in the example. It's very intuitive and is much more elegant than destructing in the function body. Cole > On May 6, 2016, at 2:05 AM, Goffredo Marocchi via swift-evolution > wrote: > > +1 it

Re: [swift-evolution] Making `.self` After `Type` Optional

> On 06 May 2016, at 10:19, Adrian Zubarev via swift-evolution > wrote: > > Wouldn’t this enforce enum cases and some static struct variables to be > lowercase? > > Is this really a welcome change? I mean I’d love to see the drop of `.self` > magic from types, but

Re: [swift-evolution] Making `.self` After `Type` Optional

Wouldn’t this enforce enum cases and some static struct variables to be lowercase? public enum UINavigationControllerOperation: Int {          case None     case Push     case Pop } public struct NSLayoutFormatOptions: OptionSetType {     public init(rawValue: UInt)          public static var

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

I don't know if it's considered too late at this point to rename 'reduce', but I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. 'Fold' is just as obvious a name as 'reduce', IMO (actually I even prefer it). I think changing it now with other source-breaking changes is

Re: [swift-evolution] Making `.self` After `Type` Optional

> I understand why the alternative of changing the generic type parameter list > symbols was rejected, to be consistent with other C based languages, but I > don't understand why the following was rejected: > > making the UppercaseTypes, lowercaseValues convention a syntactic > requirement, as

Re: [swift-evolution] Making `.self` After `Type` Optional

+1 to David's point. Given that Swift's naming conventions already diverge from C's (and we have things like 'Self' vs 'self'), it seems like enforcing this relatively uncontroversial best practice would be an overall win. Austin > On May 6, 2016, at 12:04 AM, David Hart via swift-evolution >

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

+1 it improves readability a lot and thus should be encouraged. [[iOS messageWithData:ideas] broadcast] > On 6 May 2016, at 07:57, Thorsten Seitz via swift-evolution > wrote: > > +1 > > I do like the syntax suggested by Dennis. Making use of Swift's ability to >

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Definitely a welcome change from me (+1). But this proposal makes me curious about the impact on the `AnyObject` protocol? let string = "foo" let nsString = string as AnyObject nsString.dynamicType // _NSCFConstantString.Type NSString().dynamicType // __NSCFConstantString.Type // there are two

Re: [swift-evolution] Making `.self` After `Type` Optional

I understand why the alternative of changing the generic type parameter list symbols was rejected, to be consistent with other C based languages, but I don't understand why the following was rejected: making the UppercaseTypes, lowercaseValues convention a syntactic requirement, as is done in

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

+1 I do like the syntax suggested by Dennis. Making use of Swift's ability to differentiate between external and internal parameter names is a great idea! -Thorsten Am 06. Mai 2016 um 06:25 schrieb "T.J. Usiyan via swift-evolution" : +1  I have wanted this

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

> assert( xml != ei""" > > >\(author) >XML Developer's Guide >Computer >44.95 >2000-10-01 >An in-depth look at creating applications > with

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

If we are discussing naming changes to reduce, here's my personal opinion: * When I first encountered it, I understood exactly what it did because I knew that term of art. If it was named sequence, I would have been confused. * If we are discussing name changes, I'd personally vote to change it

[swift-evolution] [Accepted] SE-0066: Standardize function type argument syntax to require parentheses

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md Hello Swift community, The review of SE-0066 “Standardize function type argument syntax to require parentheses” ran from April 25...May 2, 2016. The proposal is accepted for