Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

Additive idea, but +1 for looping on ranges without the need on an index. --  Adrian Zubarev Sent with Airmail Am 1. Juli 2016 um 09:39:23, Diego Barros via swift-evolution (swift-evolution@swift.org) schrieb: When you want a simple `for` loop, for example: for _ in 1...10 { // do

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

We haven’t pass the dave test yet? :D Still curious what he’d say about Syntax.Literal.*Protocol One more question: What can the namespace Syntax could be used for except for literals, any idea? (I have no clue.) --  Adrian Zubarev Sent with Airmail Am 30. Juni 2016 um 03:30:15, Matthew

[swift-evolution] [Proposal] Union Type

https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md Hi, I'm now officially proposal the union type feature for Swift. Please see:

Re: [swift-evolution] [Proposal] Sealed classes by default

> That starts to look an awful lot like a fifth access level just for classes > (I know you're not proposing one, but it could start to look that way to a > user). You know, it *could* be. Suppose that, in `internal` scope, you can do all of these things: * Subclass a class. * Add a case to

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Jordan, Thanks for the very insightful explanation! It all makes a lot of sense in perspective. Apparently I was thinking about this issue a bit while I was sleeping, and now it seems to me that part of the problem is because one strives for the function signature to be linguistically

[swift-evolution] Overrides in class extensions

Hi there! the Swift book says: > Extensions in Swift can: > > • Add computed instance properties and computed type properties > • Define instance methods and type methods > • Provide new initializers > • Define subscripts > • Define and use new nested types > • Make an existing type conform to

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> The review of "SE-0113: Add integral rounding functions to FloatingPoint" > begins now and runs through July 5. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md > >* What is your

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

On Jun 30, 2016, at 9:12 PM, Dave Abrahams via swift-evolution wrote: > I don't believe that “stride” *is* the accepted term of art for this > meaning. I never heard of the idea of types having an intrinsic > “stride” until I arrived on the Swift project. That usage

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 7:44 AM, Joseph Lord via swift-evolution > wrote: > > >> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >> begins now and runs through July 5. The proposal is available here: >> >> >>

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

+1, having to add an underscore in a X.times loop always feels contrived. On Fri, Jul 1, 2016 at 2:38 AM, Diego Barros via swift-evolution < swift-evolution@swift.org> wrote: > When you want a simple `for` loop, for example: > > for _ in 1...10 { > > // do something 10 times > > } > > > Clean-up

[swift-evolution] [Probe] The automatically generated init for structs

My apologies if this was resolved before. At one point there was a suggestion for the access level for the auto-generated init for structs. The issue was that the access level is internal by default. If you want to make this init public you have to implement the init yourself - there is no

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Nice and swifty, +1 This is a nice addition to the standard library that removes a common reason C libraries had to be imported. On Thu, Jun 30, 2016 at 11:02 PM Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0113: Add integral rounding functions to

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

> On Jun 30, 2016, at 12:58 PM, Edward Valentini via swift-evolution > wrote: > > > I am finding myself in a situation where the most elegant "swifty" solution > would be to allow enum extensions to add to existing case options. For > example lets say I'm using a

Re: [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?

+1 for Swift 3. Sent from my iPhone > On 1 Jul 2016, at 04:08, Douglas Gregor via swift-evolution > wrote: > > >> On Jun 30, 2016, at 3:16 PM, Ayaka Nonaka via swift-evolution >> wrote: >> >> Hi Swift community, >> >> I was wondering

Re: [swift-evolution] [Proposal] Sealed classes by default

> If we're going to go along those lines, we should just use > public(subclassable) and public(overridable). We can fall back on those if > necessary; I would just like to continue looking for better alternatives. I would prefer to have a *single* keyword which meant both public and

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

Bah, of course. No point in trying to qualify the word; let's just call it the memory layout stride and be done with it. On Fri, Jul 1, 2016 at 02:05 Dave Abrahams wrote: > No, actually both can be something other than the minimum. These are > usually going to be the

Re: [swift-evolution] [Proposal] Sealed classes by default

That starts to look an awful lot like a fifth access level just for classes (I know you're not proposing one, but it could start to look that way to a user). I think there's much to be said for having the word public in front of things that are public. Unless, of course, your strawman keyword is a

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 30 Jun 2016, at 23:39, Dave Abrahams wrote: > All multi-pass sequences can benefit from subscripts. Sorry, not really what I meant, but rather; how many sequences are really going to use them? > It's trivial; the index contains the iteration state. The only >

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Great story! What gets us from 95% to 100%? :) > On 1 Jul 2016, at 05:33, Jordan Rose via swift-evolution > wrote: > > >>> On Jun 30, 2016, at 13:36, Taras Zakharko via swift-evolution >>> wrote: >>> >>> >>> On 30 Jun 2016, at 22:11,

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

I don't think it needs qualifying. It cannot be anything other than the minimum, just like we have `alignment` instead of `minimumAlignment`. On Fri, Jul 1, 2016 at 00:50 Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > There seems to be agreement that "stride" is

[swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

When you want a simple `for` loop, for example: for _ in 1...10 { // do something 10 times } Clean-up and simplify the syntax by removing the superfluous underscore and `in`: for 1...10 { // do something 10 times } -- diego ___ swift-evolution

[swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Hello Swift community, The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md Reviews are

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

It's not the minimum though. Just go with stride already  Sent from my illudium Q-36 explosive space modulator > On Jun 30, 2016, at 10:49 PM, Jacob Bandes-Storch wrote: > > There seems to be agreement that "stride" is sensical term for the distance > between values in

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

No, actually both can be something other than the minimum. These are usually going to be the minimum-without-performance-degradation. Sent from my illudium Q-36 explosive space modulator > On Jun 30, 2016, at 11:29 PM, Xiaodi Wu wrote: > > I don't think it needs

[swift-evolution] [Discussion] Can we make `.Type` Hashable?

Additive question: Can a type instance of a type SomeType.self SomeType.Type be Hashable? I really would want to use these in dictionaries or sets :) [Any.Type: ValueType] Set // Union type universe --  Adrian Zubarev Sent with Airmail ___

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

If we go with the “Compiler” alternative, it might make sense to put things like the language/toolchain version, host, target, etc there: if Compiler.language.version >= 3 { celebrate() } if Compiler.target.cpuCount * Compiler.target.coreCount > someValue {/* parallelize something differently

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1. I've had to do this a couple times and ended up wrapping them in string interpolations, which makes me feel terrible. On Fri, Jul 1, 2016 at 6:26 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > On Jul 1, 2016, at 8:20 AM, Adrian Zubarev via swift-evolution <

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1 here, too. Looking like someone needs to write a full proposal! :P l8r Sean > On Jul 1, 2016, at 9:11 AM, Tony Allevato via swift-evolution > wrote: > > +1. I've had to do this a couple times and ended up wrapping them in string > interpolations, which makes me

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1 here as well. It would be nice to have. > On Jul 1, 2016, at 9:15 AM, Sean Heber via swift-evolution > wrote: > > +1 here, too. Looking like someone needs to write a full proposal! :P > > l8r > Sean > > >> On Jul 1, 2016, at 9:11 AM, Tony Allevato via

[swift-evolution] Variadics through tuples

Currently, the following code is allowed: //function application operator infix operator => {} func =>(a: In, b: In -> Out) -> Out { return try b(a) } infix operator ?=> {} func ?=>(a: In?, b: In -> Out?) -> Out? { if let unwrapped = a { return try b(a) }

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

I’ll do it when we get the go for such additive proposals. --  Adrian Zubarev Sent with Airmail Am 1. Juli 2016 um 16:15:48, Sean Heber (s...@fifthace.com) schrieb: +1 here, too. Looking like someone needs to write a full proposal! :P l8r Sean > On Jul 1, 2016, at 9:11 AM, Tony

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

Minor, but I think I'd be onboard as well. Once proposed (and assuming it was approved), this would likely be deferred until post Swift 3 since it’s additive. l8r Sean > On Jul 1, 2016, at 2:38 AM, Diego Barros via swift-evolution > wrote: > > When you want a

Re: [swift-evolution] [Proposal] Union Type

But in the union type design, String == String | String, this is always true > I already answered that question: > > For example: > > typealias ABC = A | B | C > > typealias ABCD = ABC | D > > we just use an existed type ABC to construct ABCD > > But how about generic wrap? > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

* What is your evaluation of the proposal? + 1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. When inference goes wrong it is frustrating and difficult to puzzle out. * Does this proposal fit well with the feel and direction of Swift?

Re: [swift-evolution] [apple/swift-evolution] Proposal: Union Type

> 下面是被转发的邮件： > > 发件人: Cao Jiannan > 主题: 回复： [apple/swift-evolution] Proposal: Union Type (#404) > 日期: 2016年7月1日 GMT+8 21:22:32 > 收件人: apple/swift-evolution > > >

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1 > On Jul 1, 2016, at 8:20 AM, Adrian Zubarev via swift-evolution > wrote: > > Additive question: > > Can a type instance of a type SomeType.self SomeType.Type be Hashable? > I really would want to use these in dictionaries or sets :) > > [Any.Type: ValueType] >

Re: [swift-evolution] [Proposal] Union Type

what if OneOf? duplicate variable compile warning? I already answered that question: For example: typealias ABC = A | B | C typealias ABCD = ABC | D we just use an existed type ABC to construct ABCD But how about generic wrap? Bikeshedding: // we generate the boundary with `A | B` or

Re: [swift-evolution] [Proposal] Union Type

I can't compile your code. I'm really not sure your code will pass the complex generic check  Union version more complex or generic version? I think union version is more normal. > For example: > > typealias ABC = A | B | C > > typealias ABCD = ABC | D > > we just use an existed type ABC to

Re: [swift-evolution] [Proposal] Union Type

what if OneOf? duplicate variable compile warning? > 在 2016年7月1日，20:59，Adrian Z. > 写道： > > Just one simple thing to add: > > If ...T equals 10 then <...T, U> = 10 + 1 = 11 types > If ...U equals 17 then = 1 + 17 = 18

Re: [swift-evolution] [Proposal] Union Type

T_T I’ve never said it will compile (the second time now), I’ve said couple of times its just future bikeshedding with variadic generics from the generics manifesto and variadic enum cases that I come up with. --  Adrian Zubarev Sent with Airmail Am 1. Juli 2016 um 15:33:41, Cao Jiannan via

[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> What is your evaluation of the proposal? -1. Argument labels can have meaning and are very useful, especially for default parameter names in closures: ```// Declaration func handleResponse(handler: (response: Response) -> ()) // Callsite handleResponse { response in // response automatically

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Brent Royal-Gordon wrote: >> On Jul 1, 2016, at 12:34 AM, Haravikk wrote: >> >> Sequences are currently dead easy to implement, and to implement in >> an ad-hoc way via AnySequence(body:), how would that be done under >> this required indexing

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Haravikk wrote: >> On 30 Jun 2016, at 23:39, Dave Abrahams wrote: >> All multi-pass sequences can benefit from subscripts. > > Sorry, not really what I meant, but rather; how many sequences are > really going to use them? The subscript and index aren't

[swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> What is your evaluation of the proposal? I think it’s good to have this functionality in the standard library, but it seems a bit inconsistent with other Swift math operators which are declared as global functions such as abs, max, +, -, /, *, %, etc. > Is the problem being addressed

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

The best way to pass the Dave Test is to ask him directly, for example: Dave: Do you think the stdlib team would be okay with a naming scheme like Syntax.Literal.ArrayProtocol, Syntax.Literal.IntegerProtocol, etc. We think this produces a clear description of the conformant role and one that

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

On Fri, Jul 1, 2016 at 11:51 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 01 2016, Matthew Johnson wrote: > > >> On Jun 30, 2016, at 12:26 PM, Dave Abrahams > > wrote: > >> > >> > >> on Wed Jun 29 2016, Haravikk wrote: > >> > > >

Re: [swift-evolution] Include sqrt and remainder into FloatingPoint protocol as built in functions as required by IEEE754

As mentioned in the other thread, these are already accepted for inclusion as part of SE-0067. On Fri, Jul 1, 2016 at 10:35 Björn Forster wrote: > The IEEE754 standard requires a standard conform floating point > implementation besides add,mul,sub,div and rounding

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu wrote: > On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution > > wrote: > > on Thu Jun 30 2016, John McCall wrote: > > >> On Jun 30, 2016, at 6:12 PM,

[swift-evolution] [Pitch] Self.withoutSpecialization

## The Issue Given ``` swift public protocol Zipper1D : CustomStringConvertible { associatedtype Element } ``` We can almost write a `flatMap` which keeps the general identity of self and swaps out the Element in the output. ``` swift func flatMap< NewElement, SegmentOfResult :

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jul 1, 2016, at 11:00 AM, Erica Sadun wrote: > > The best way to pass the Dave Test is to ask him directly, for example: > > Dave: > > Do you think the stdlib team would be okay with a naming scheme like > Syntax.Literal.ArrayProtocol,

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Mostly I was just hedging my bets, but the main one I can think of is that enum cases still use tuples, which means they don’t have distinct argument labels and preserve the labels in switches. There’s also a bunch of implementation improvements we can make (like fixing mangling and printing of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md ] Just wondering, why no 'awayFromZero' case?

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 10:13, Stephen Canon wrote: > >> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution >> > wrote: >> >> [Proposal: >>

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution > wrote: > > >> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >> begins now and runs through July 5. The proposal is available here: >> >> >>

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

John McCall via swift-evolution writes: > > There is a high chance that 'higherThan'/'lowerThan' names will be > > chosen. I still see a problem with that. Keywords in Swift are written > > in full lowercase, so we should actually take 'higherthan'/'lowerthan'. > > > >

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:14 PM, Karl via swift-evolution > wrote: > > >> On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution >> wrote: >> >> >>> The review of "SE-0113: Add integral rounding functions to FloatingPoint" >>> begins

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Given that 2 * pi is always as precise as pi itself, I really can't understand the clamor for such a constant in the stdlib. It can be defined both correctly and trivially by anyone who wants it. On Fri, Jul 1, 2016 at 12:21 Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > >

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Note under the latest floating point and integer protocol proposals the operators you outlined are basically overlays of the protocol functions even abs is replaced with magnitude on a protocol. Sorry not in a situation to link out to the proposals. On Fri, Jul 1, 2016 at 7:51 AM Brad Hilton via

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jun 30, 2016, at 5:32 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Jun 30 2016, Xiaodi Wu > > wrote: >> >>> If Iterators become reference types that model

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jul 1, 2016, at 8:57 AM, John McCall via swift-evolution > wrote: >> On Jun 30, 2016, at 10:41 PM, Xiaodi Wu > > wrote: >> On Fri, Jul 1, 2016 at 12:03 AM, Dave Abrahams via swift-evolution >>

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

Joe Groff via swift-evolution writes: > To reiterate the core team's rationale, precedence groups ought to be a relatively rare thing. Few users > ought to be defining new operators, fewer still new precedence groups. Furthermore, the '-Precedence' > word clarifies the use

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon wrote: >> That starts to look an awful lot like a fifth access level just for classes >> (I know you're not proposing one, but it could start to look that way to a >> user). > > You know, it *could* be. > > Suppose that,

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu wrote: > That starts to look an awful lot like a fifth access level just for classes > (I know you're not proposing one, but it could start to look that way to a > user). I think there's much to be said for having the word public in

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jun 30, 2016, at 12:26 PM, Dave Abrahams > wrote: >> >> >> on Wed Jun 29 2016, Haravikk wrote: >> > On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution wrote:

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jun 30, 2016, at 5:39 PM, Dave Abrahams wrote: >> >> >> on Thu Jun 30 2016, Haravikk wrote: >> > On 30 Jun 2016, at 18:26, Dave Abrahams wrote: Q: Why should there be indices on an

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jul 1, 2016, at 9:47 AM, Dave Abrahams wrote: >> >> >> on Fri Jul 01 2016, Haravikk wrote: >> > On 30 Jun 2016, at 23:39, Dave Abrahams wrote: All multi-pass sequences can benefit from

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 1:30 AM, Taras Zakharko via swift-evolution > wrote: > > Jordan, Thanks for the very insightful explanation! It all makes a lot of > sense in perspective. > > Apparently I was thinking about this issue a bit while I was sleeping, and > now it

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 7:37 AM, Brad Hilton via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > -1. Argument labels can have meaning and are very useful, especially for > default parameter names in closures: > > ```// Declaration > func

Re: [swift-evolution] [Proposal] Union Type

> On Jul 1, 2016, at 2:08 AM, Cao Jiannan via swift-evolution > wrote: > > > > Hi all, > > I'm now officially proposal the union type feature for Swift. Please see: > > > https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md >

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

* What is your evaluation of the proposal? a reluctant +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. * 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] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md > >

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

These are already included with SE-0067, we’re just working on finishing up the implementation. /// Remainder of `self` divided by `other`. This is the IEEE 754 remainder /// operation. /// /// For finite `self` and `other`, the remainder `r` is defined by /// `r = self - other*n`,

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 12:26 PM, Dave Abrahams wrote: > > > on Wed Jun 29 2016, Haravikk wrote: > >>> On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Swift is a language that embraces value semantics. Many

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 5:39 PM, Dave Abrahams wrote: > > > on Thu Jun 30 2016, Haravikk wrote: > >>> On 30 Jun 2016, at 18:26, Dave Abrahams wrote: >>> >>> Q: Why should there be indices on an infinite multipass sequence? >>> A: Because the

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 5:32 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jun 30 2016, Xiaodi Wu > wrote: > >> If Iterators become reference types that model single-pass sequences and >> becomes for-in-able, as the

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 9:47 AM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Haravikk wrote: > >>> On 30 Jun 2016, at 23:39, Dave Abrahams wrote: >>> All multi-pass sequences can benefit from subscripts. >> >> Sorry, not really what I meant, but

Re: [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats

> On Jul 1, 2016, at 6:12 AM, Björn Forster via swift-evolution > wrote: > > In SE-0067: Enhanced Floating Point Protocols > > is stated that pi will be a built in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution > wrote: > >> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution >> > wrote: >> >> [Proposal: >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On Jul 1, 2016, at 1:20 PM, Erica Sadun wrote: > > >> On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution >> > wrote: >> >>> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Proposal] Sealed classes by default

The proposal was to use "sealed" so why not "opened"? I understand it may not be common to use "opened" as an adjective but from the dictionaries I consulted it is possible to. opened class MyViewController: UIViewController { opened func displayMe(_ me: person) { … } } On 1 July 2016 at

[swift-evolution] Fwd: [Proposal] Union Type

My proposal begins on February, still in May. But may no make attention to you. This proposal is more about how to change the way of thinking optional/either type. Change the way of using generic to construct optional/either type. > 下面是被转发的邮件： > > 发件人: Joe Groff > 主题: 回复：

Re: [swift-evolution] [Proposal] Sealed classes by default

Coming in late on this, but here’s my take guided by the principal of least surprise (according to me): - everything is sealed within its module by default, no keyword - use “public” to mean “exported out of the module, subclass/overridable” - use “public(final)” to mean “exported out of the

Re: [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats

> On Jul 1, 2016, at 10:05 AM, Erica Sadun via swift-evolution > > wrote: > > >> On Jul 1, 2016, at 6:12 AM, Björn Forster via swift-evolution >> > wrote: >> >> In

Re: [swift-evolution] Besides pi, include also e as a builtin mathematical constant into floats

> On Jul 1, 2016, at 2:33 PM, David Waite via swift-evolution > wrote: > > That only is about tau, which is a much more controversial operator. > Unfortunately, I wasn’t able to find the discussion of pi or E in the > archives (but neither pi nor e are very

Re: [swift-evolution] renaming CustomStringConvertible

On 01.07.2016 22:16, Eric Habberstad via swift-evolution wrote: To the Swift community, May I put forth a couple of new names for the following protocol: - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’ Strong +1 from me. It looks and reads nice, clearly shows the

Re: [swift-evolution] renaming CustomStringConvertible

Maybe... It's just a property, though. I think if something's moving into the Syntax thing, I'd rather look for a way to move string interpolation there. Maybe. - Dave Sweeris > On Jul 1, 2016, at 14:24, Xiaodi Wu via swift-evolution > wrote: > > Perhaps another

Re: [swift-evolution] [Proposal] Union Type

@core team: should the be added to the list of common rejections for now or does it stand a chance in the next 2 or 3 versions? Regards LM (From mobile) > On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution > wrote: > >

Re: [swift-evolution] Variadics through tuples

Yes, I expect that with the implemented proposal SE-0110 your code will not compile because `moveTo` has type `(Int, Int)->Void` and not required `((Int, Int))->Void`. You'll need to change the moveTo to accept tuple argument or use some function/operator to transform argument list

Re: [swift-evolution] [Proposal] Union Type

It’s already on that list. That’s what Joe was quoting from earlier. Everybody (I hope) understands the “something the type system cannot […] support” part, but if the “should not” bit were expanded a bit so that people would know why it shouldn’t be supported… The closest I ever saw to a

[swift-evolution] renaming CustomStringConvertible

To the Swift community, May I put forth a couple of new names for the following protocol: - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’ Two goals for Swift is clarity and joy in use of the language, so I strongly feel that ‘Custom-‘ not be part of any new name

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jul 1, 2016, at 1:03 AM, Dave Abrahams via swift-evolution > wrote: > > It's not the minimum though. Just go with stride already  > Changing to stride. > Sent from my illudium Q-36 explosive space modulator -- Sent from the HQ of the Ravenous Bugblatter

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

That makes sense, thanks for letting us know. Dan On Thu, Jun 30, 2016 at 11:32 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 30, 2016, at 12:58 PM, Edward Valentini via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > I am finding myself

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

This would be great. I've solved this recently by making a TypeRepresentation type that is initialized with any T, and conforms to Hashable. Of course internally this just uses String(T), but at least that's abstracted from the caller. -- Keith Smiley On 07/01, Matthew Johnson via

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

on Wed Jun 29 2016, Anton Zhilin wrote: > Dave Abrahams via swift-evolution writes: > >> I've updated my pull request with a much more conservative set of >> changes that preserves/restores label-free-ness for all “term of art” >> functional

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

on Fri Jul 01 2016, Adrian Zubarev wrote: > The only problem I can see with ExpressibleAs is that it also reads if > I could potentially do something like this type <-> literal, People keep going down that road, but I don't see why. As far as I know, “A is

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

on Wed Jun 29 2016, Matthew Johnson wrote: > Sent from my iPad > >> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> I've updated my pull request with a much more conservative set of >> changes that

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Wed Jun 29 2016, Brent Royal-Gordon wrote: > We might even be able to take the existing string-to-integer > logic, which I believe is duplicated for each type through GYB, and > share it in an extension so no Integer needs to write its own > conversion. Is that

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 4:12 PM, Douglas Gregor via swift-evolution > wrote: > > FYI, in-progress implementation is available at: > > https://github.com/apple/swift/tree/nserror-bridging > > > The only issue

Re: [swift-evolution] renaming CustomStringConvertible

on Fri Jul 01 2016, Dmitri Gribenko wrote: > On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution > wrote: >> >> To the Swift community, >> >> May I put forth a couple of new names for the following protocol: >> >> >> -

  1   2   >