Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

I merged the last of my edits to this proposal (see the PR below), if anyone it interested in seeing where things ended up and doing last minute reviews. https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md -Andy > On Jul 10, 2016, at 6:41 AM, Andrew Trick wr

Re: [swift-evolution] Change subscripts to use colons

Then it kinda looks like your subscripting a property called `image`, doesn’t it? > On 12 Jul 2016, at 08:24, David Hart wrote: > > How about a proposal for named subscripts? > > button.image[for: .normal] = image > > defined using: > > subscript image(for: UIControlState): UIImage? { >

Re: [swift-evolution] Optional comparison operators

Mark, Thanks for writing this up. Just to clarify, will these still work if your proposal is implemented? let x: Int? let y: Int struct NotEquatable {} let z: NotEquatable? x == y; x != y x == nil; x != nil z == nil; z != nil I would hope that these continue to work.

Re: [swift-evolution] Change subscripts to use colons

Feels like an abuse of subscripting IMHO. I'm fine with parametrized properties but the subscript doesn't quite fit in this case. Sent from my Apple Watch On Jul 11, 2016, at 23:24, David Hart via swift-evolution wrote: > How about a proposal for named subscripts? > > button.image[for: .nor

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

>> Safety is valued, but Swift cares (and should care!) about pragmatism as >> well… the most obvious example that comes to my mind are arrays, which have >> no safeguards that stop you from accessing elements that aren't there. > > I'm not sure I understand this point. First, a guaranteed runti

Re: [swift-evolution] Optional comparison operators

David, The proposal Mark is working on doesn't remove the operators which accept optional values. It simply removes the ability to pass non-optional values to them without explicit casting/coercion. In that example y doesn't need to be coerced. I'm currently writing up a separate proposal to remov

Re: [swift-evolution] Optional comparison operators

There’s something I don’t understand about the proposal. How can the following code still be valid if the proposal is accepted: let x: Int! = 5 let y: Int? = 7 print(x < y) // true Isn’t there going to be a problem coercing y? David. > On 12 Jul 2016, at 08:22, Mark Lacey via swift-evolution

Re: [swift-evolution] Change subscripts to use colons

How about a proposal for named subscripts? button.image[for: .normal] = image defined using: subscript image(for: UIControlState): UIImage? { get { … } set { … } } > On 12 Jul 2016, at 00:29, Tim Vermeulen via swift-evolution > wrote: > > >> On 12 Jul 2016, at 00:20, Jacob B

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:54 PM, Chris Lattner wrote: > >> >> On Jul 11, 2016, at 9:35 PM, Mark Lacey > > wrote: >> >> >>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Jul 11, 2016, a

Re: [swift-evolution] [Pitch] Require "infix" for infix operator function declarations

+1 Personally this one wouldn’t bother me to require, but It seems the Swift way is to not require things that can be inferred by context so I’m ok with just allowing it. > On Jul 11, 2016, at 9:03 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Currently, "infix" is not required/al

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

-1 for this proposal, but +1 for solving the issues it raises Regardless of what ends up being the defaults, I’m a very strong -1 on conflating visibility and subclassability/extendability. - Dave Sweeris > On Jul 5, 2016, at 6:11 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swif

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

+1 for the feature, +0.5 for being it the default and -1 for they syntax. I'd prefer `open`, maybe `public(open)` or probably better `public open`. I think library design is important and so this is a problem worth solving. I read the proposal and followed the discussion. -Thorsten > Am 06.07.

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:35 PM, Mark Lacey wrote: > > >> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] adding Obj-C syntax to Swift?

> On Jul 11, 2016, at 8:00 PM, Ford Prefect via swift-evolution > wrote: > > Perhaps one of the most disliked aspects of Swift > is the Rust-like syntax, which requires that each coder resign himself to > grin-and-bear-it in order to obtain the benefits of Swift. > Since "the writing is on the

Re: [swift-evolution] [Pitch] Require "infix" for infix operator function declarations

I wouldn’t go as far as to require it, but having it for optional use “for symmetry" seems fine to me. > On Jul 11, 2016, at 21:03, Jacob Bandes-Storch via swift-evolution > wrote: > > Currently, "infix" is not required/allowed on an operator function > definition, but "prefix" and "postfix"

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> You'd have to unwrap it, or use the ??/==/!= operators: >> https://gist.github.com/jtbande

Re: [swift-evolution] adding Obj-C syntax to Swift?

I'm personally not in favor of any change for which the main argument seems to be "I like it better this way". Félix > Le 11 juil. 2016 à 20:00:14, Ford Prefect via swift-evolution > a écrit : > > Perhaps one of the most disliked aspects of Swift > is the Rust-like syntax, which requires that

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

Wow, thanks! I’m delighted that Apple found this improvement to be worth inclusion in Swift 3. This will truly make the language much nicer to use with the Cocoa frameworks. Thanks! Charles > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution > wrote: > > Proposal Link: > http

Re: [swift-evolution] adding Obj-C syntax to Swift?

My reply didn’t go to the list… my apologies… On Jul 11, 2016, at 8:19 PM, Ford Prefect mailto:ford...@mail.com>> wrote: People say nearly every WWDC code example was Swift. That says to newcomers "learn Swift, not Obj C". Swift is being ported on other platforms but Objective C is not. Google

[swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md The review of "SE-0112: Improved NSError Bridging" ran from June 30 ... July 4, 2016. The proposal has been *accepted*: The community and core team agree that this proposal is a huge step forw

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > You'd have to unwrap it, or use the ??/==/!= operators: > https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38 > > > I'd be okay with />= returning Boo

[swift-evolution] [Pitch] Require "infix" for infix operator function declarations

Currently, "infix" is not required/allowed on an operator function definition, but "prefix" and "postfix" are: prefix operator ^^ {} // valid postfix operator ^^ {} // valid infix operator ^^ {}// valid prefix func ^^(operand: Int) {} // valid postfix func ^^(operand:

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 6:02 PM, Jacob Bandes-Storch wrote: > > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner > wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Personally I think we should j

Re: [swift-evolution] adding Obj-C syntax to Swift?

Not quite sure what you mean. Swift is designed to be somewhat similar to C and C++; the “Rust-like” syntax is merely because Rust does it like C does. > On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution > wrote: > > Perhaps one of the most disliked aspects of Swift > is the Rust-like

Re: [swift-evolution] Optional comparison operators

You'd have to unwrap it, or use the ??/==/!= operators: https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38 I'd be okay with />= returning Bool?, as I suggested in an older email (which somehow didn't make it to gmane's archive, but it's quoted in some other messages

Re: [swift-evolution] Optional comparison operators

Correct me if I’m wrong, but wouldn’t you have to unwrap every comparison then? > On Jul 11, 2016, at 20:02, David Sweeris via swift-evolution > wrote: > > Why not have them return a `Bool?`? If both arguments are non-nil, it can > return the results of the comparison, otherwise it can return n

[swift-evolution] Improve Swift APIs for NSExpression and NSIncrementalStore

Apologies if this has been discussed, I couldn't find any mention in the list or on https://github.com/apple/swift-3-api-guidelines-review. The NSIncrementalStore method: func referenceObjectForObjectID(_ objectID: NSManagedObjectID) -> AnyObject Can thrown an exception, but it's not marked

Re: [swift-evolution] Optional comparison operators

Why not have them return a `Bool?`? If both arguments are non-nil, it can return the results of the comparison, otherwise it can return nil. - Dave Sweeris > On Jul 7, 2016, at 16:37, Jacob Bandes-Storch via swift-evolution > wrote: > > These operators cause some potential for confusion: > >

[swift-evolution] adding Obj-C syntax to Swift?

Perhaps one of the most disliked aspects of Swift is the Rust-like syntax, which requires that each coder resign himself to grin-and-bear-it in order to obtain the benefits of Swift. Since "the writing is on the wall" that Objective C is in its last days at least as far as app writers go (mayb

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

> On Jul 11, 2016, at 7:34 PM, Jacob Bandes-Storch wrote: > > I'd call it an antipattern: it pretty much defeats the purpose of having the > ExpressibleBy*Literal protocols. > > If you just want a type to be constructible from a value of some other type > (literal or not), that's what regular

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 8:02 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner wrote: > >> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote: >> > Personally I t

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Personally I think we should just remove these optional-taking variants > of the comparison operators. Does anyone agree/disagree?

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 5:29 PM, Mark Lacey via swift-evolution > wrote: > > >> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch > > wrote: >> >> Personally I think we should just remove these optional-taking variants of >> the comparison operators. Does anyone agree

Re: [swift-evolution] Optional comparison operators

On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution wrote: > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agree/disagree? > > It does make sense to keep ==(T?, T?) and !=(T?, T?), and if coercion were > remo

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:29 PM, Mark Lacey wrote: > > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch > wrote: > > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agree/disagree? > > > I believe that a well-defined ordering of

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:32 PM, Mark Lacey wrote: > > On Jul 11, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Yup, I too would prefer removing the functions over removing coercion. > > > Hi Xiaodi, > > Is there a reason you think the coercion is important to keep? > > I see these as somewhat orthogon

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

I'd call it an antipattern: it pretty much defeats the purpose of having the ExpressibleBy*Literal protocols. If you just want a type to be constructible from a value of some other type (literal or not), that's what regular initializers are for. For example, in addition to its ArrayLiteralConverti

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Yup, I too would prefer removing the functions over removing coercion. Hi Xiaodi, Is there a reason you think the coercion is important to keep? I see these as somewhat orthogonal issues (allowing or disallowing coercion vs. keeping or remo

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

> On 2016-07-12, at 01:54, Colin Cornaby wrote: > >> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of >> things in Swift that subtly or openly discourage people from subclassing. >> How far are we from someone seriously proposing to outright rip inheritance >> out

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch wrote: > > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agree/disagree? I believe that a well-defined ordering of optionals and non-optionals is required in order to allow

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

> On Jul 11, 2016, at 19:13, Jacob Bandes-Storch via swift-evolution > wrote: > > I'd be happy with a warning + fix-it too. > >> On Mon, Jul 11, 2016 at 5:05 PM, Xiaodi Wu wrote: >> Maybe just a warning + fix-it would be sufficient? >> >>> On Mon, Jul 11, 2016 at 19:02 Jacob Bandes-Storch vi

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

> On Jul 11, 2016, at 8:30 AM, Ankit Agarwal via swift-build-dev > wrote: > > > 1. One major reason for wanting control over which targets are exported are > so packages can control which parts of their API is supported for external > use. This is very important to large projects undergoing

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

I'd be happy with a warning + fix-it too. What's the right way to do this? An attribute like "@implicit" on the initializers? Perhaps a special case in the compiler, since these are already "known protocol kinds"

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

Maybe just a warning + fix-it would be sufficient? On Mon, Jul 11, 2016 at 19:02 Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Tangential: Is there any way to make it impossible to call these > literal-initializers explicitly, instead requiring " as T" or just > ""

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

Tangential: Is there any way to make it impossible to call these literal-initializers explicitly, instead requiring " as T" or just "" in a typed context? I have seen several explicit calls of these initializers where literals would have been more appropriate, such as "Set(arrayLiteral: foo, bar)"

Re: [swift-evolution] Optional comparison operators

Yup, I too would prefer removing the functions over removing coercion. On Mon, Jul 11, 2016 at 18:57 Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agr

Re: [swift-evolution] Optional comparison operators

Personally I think we should just remove these optional-taking variants of the comparison operators. Does anyone agree/disagree? It does make sense to keep ==(T?, T?) and !=(T?, T?), and if coercion were removed, we might want to add (T, T?) and (T?, T) versions. Are there any other operators that

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

> - Slippery Slope: SE-0117 adds yet another entry to the already huge list of > things in Swift that subtly or openly discourage people from subclassing. How > far are we from someone seriously proposing to outright rip inheritance out > of the language? Enough is enough. Stop with the anti-sub

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0115: Rename Literal Syntax Protocols

Does this one have an SR number yet? It would make for a fantastic starter bug. > On Jul 11, 2016, at 4:16 PM, Chris Lattner wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md > > The review of "SE-0115: Rename Literal S

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch wrote: > > Great, thanks Mark! I look forward to it. To be clear, I’m specifically looking at making the change to remove the coercion from T to T? for operator arguments. I agree there might be other things worth looking at regarding operato

Re: [swift-evolution] Optional comparison operators

Great, thanks Mark! I look forward to it. On Mon, Jul 11, 2016 at 4:31 PM, Mark Lacey wrote: > Hi Jacob, > > On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Bump for Swift 3. > > On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch >

Re: [swift-evolution] Optional comparison operators

Hi Jacob, > On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Bump for Swift 3. > > On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch > wrote: > These operators cause some potential for confusion: > > public func <(lhs: T?, rhs

Re: [swift-evolution] Optional comparison operators

Bump for Swift 3. On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch wrote: > These operators cause some potential for confusion: > > public func <(lhs: T?, rhs: T?) -> Bool > public func >(lhs: T?, rhs: T?) -> Bool > public func <=(lhs: T?, rhs: T?) -> Bool > public func >=(lhs

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Thank you for putting your real world scenario out there too. I think you made some pragmatic points about life of application developers depending on other companies libraries and I am curious to see more debate on that point of view. On Tue, Jul 12, 2016 at 12:00 AM, Jonathan Hull via swift-evol

[swift-evolution] [Accepted] SE-0114: Updating Buffer "Value" Names to "Header" Names

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0114-buffer-naming.md The review of "SE-0114: Updating Buffer “Value” Names to “Header” Names " ran from July 1...7, 2016. The proposal has been *accepted*: The community discussion and core team unanimously agree tha

[swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md The review of "SE-0115: Rename Literal Syntax Protocols " ran from Active review July 1...7. The proposal has been *accepted*: The community and core team agree that this proposal is a

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 4:00 PM, Stephen Canon wrote: > >>> >>> I’m fine with placing a generic implementation in Darwin.C. I would >>> include that as part of this change. Post Swift 3, we should also have a >>> Swift math module that provides the usual sqrt(_: T) >>> operations. >>> >>> H

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 6:55 PM, Chris Lattner wrote: > > On Jul 11, 2016, at 3:52 PM, Stephen Canon wrote: I would also plan to provide this and other math.h-ish globals in a future (post swift 3) Math module. >>> >>> I’m very concerned with this. Why not do exactly the opposite? R

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

> On Jul 8, 2016, at 6:45 AM, Adrian Zubarev via swift-evolution > wrote: > > It’s clear that we should decide on when our observer will be executed. In > the example from above I pretended that my observer will be executed after > the observer from the module itself. > > When we set a.memb

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 10, 2016, at 7:48 PM, Rod Brown wrote: > >> On 11 Jul 2016, at 12:33 PM, Jonathan Hull wrote: >> >> It is pre-breaking in that it is the exact same code that doesn’t work in >> both cases (only in the pre-breaking case, a bunch of other code also >> doesn’t work). I know it feels d

Re: [swift-evolution] [pitch] remove global sqrt

On Jul 11, 2016, at 3:52 PM, Stephen Canon wrote: >>> I would also plan to provide this and other math.h-ish globals in a future >>> (post swift 3) Math module. >> >> I’m very concerned with this. Why not do exactly the opposite? Remove the >> concrete operations from Darwin.C and replace it

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

> On Jul 8, 2016, at 4:43 AM, Tino Heth via swift-evolution > wrote: > > There are (were?) plans for generalized property behaviors; those would be > used to implement lazy, as well as didSet/willSet, and could incorporate many > other things (including injection) Indeed, the latest draft is

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 6:42 PM, Chris Lattner wrote: > > >> On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution >> wrote: >> >> Post SE-0067 FloatingPoint provides the usual global operators, as well as a >> single global function: >> >> func sqrt(_: T) -> T >> >> It seems

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

On 2016-07-11 08:42:33 +, Tino Heth via swift-evolution said: The justification for this proposal is all about supporting the people who are working to design library APIs right, and about maintaining consistency with the design philosophy of Swift. To wit: in Swift, where there’s a defa

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

As for all of the other additive changes, I would strongly prefer you to *wait* on even proposing or discussing these things until after the Swift 3.0 evolution cycle is done. Not only is it distracting for the community, but the core team and many others won’t be be able to even read the threa

Re: [swift-evolution] [pitch] remove global sqrt

I understand that it’s only one function and that I’m probably being ever-so-slightly unreasonable but I’ve spent the last month going crazy that a language as expressive as Swift, with all of its support for protocols and generics and under-the-hood optimization, makes me do stuff like this to

Re: [swift-evolution] [pitch] remove global sqrt

Agreed. Imagine this: let distance = (x * x + y * y).squareRoot() That reads extremely foreign to me. Why not provide this as a static function that takes Self on the protocol so that conformances can specialize it, and have the protocol-constrained global function sqrt call T.sqrt? On Mon, Jul

Re: [swift-evolution] [meta] additional input during public reviews

On Jul 11, 2016, at 10:47 AM, Jose Cheyo Jimenez via swift-evolution wrote: > Hi there, > > I have noticed that on the most controversial reviews there has been a trend > of people arguing their specific stance on the proposal beyond the formal > response. I am referring to the instances when

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

> On Jul 11, 2016, at 3:39 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hey Swift Evolution! >> >> Drafted up a small proposal that harmonizes the use of static function

Re: [swift-evolution] [pitch] remove global sqrt

> On Jul 11, 2016, at 2:28 PM, Stephen Canon via swift-evolution > wrote: > > Post SE-0067 FloatingPoint provides the usual global operators, as well as a > single global function: > > func sqrt(_: T) -> T > > It seems out of place and lonely, and it would be nice if we can keep the >

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

> On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution > wrote: > > Hey Swift Evolution! > > Drafted up a small proposal that harmonizes the use of static functions and > static function properties in appropriate protocol conformance scenarios: > > https://github.com/Jasdev/swift-ev

Re: [swift-evolution] Change subscripts to use colons

> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch wrote: > > When would you want to use this instead of something like `button[imageFor: > .normal]` ? All the time, basically. Primarily because IMO it doesn’t really make sense to make “image” part of the argument label for the control state - w

Re: [swift-evolution] [pitch] remove global sqrt

The problem with having the Math module concurrent with this change is that such a thing is necessarily post-swift 3, whereas this change should happen in Swift 3 if it’s going to happen at all. Given that this only effects one function, and you already need your own wrappers for every other ma

Re: [swift-evolution] Change subscripts to use colons

When would you want to use this instead of something like `button[imageFor: .normal]` ? On Mon, Jul 11, 2016 at 3:00 PM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > Slightly related to this, I would really love to have non-subscript > parameterized properties. It would

Re: [swift-evolution] [pitch] remove global sqrt

For certain functions (sqrt, sin, cos, log, etc) we’ve grown up in math class calling them as a function on an argument rather than viewing them as a property (or method) of the number. Just like we prefer to use `a - b` rather than `a.sub(b)`, we (or at least I) prefer `sqrt(a)` over `a.square

Re: [swift-evolution] [pitch] remove global sqrt

Expanding slightly: A generic math module / protocol / whatever that provides all the math operations generically over the built-in floating point types is out of scope for the language/stdlib in Swift 3. Everyone wants it, it’s simply too late to add it (as with many other features and ponies

Re: [swift-evolution] [pitch] remove global sqrt

It wouldn’t delay code intended to operate generically at all. That code can use .squareRoot( ). > On Jul 11, 2016, at 6:12 PM, G B wrote: > > While I don’t have a strong opinion about what functions are in the global > namespace and which are in a `Math` module, I’m not excited about the ide

Re: [swift-evolution] [pitch] remove global sqrt

While I don’t have a strong opinion about what functions are in the global namespace and which are in a `Math` module, I’m not excited about the idea of delaying the availability of generic implementations of floating point functions. How would this affect code intended to operate generically o

[swift-evolution] Change subscripts to use colons

Slightly related to this, I would really love to have non-subscript parameterized properties. It would allow us to write button.image(for: .normal) = image instead of button.setImage(image, for: .normal) The same can be achieved through subscripts, but it’s not always as nice. It would bring

Re: [swift-evolution] [pitch] remove global sqrt

Seems reasonable enough. On Mon, Jul 11, 2016 at 16:28 Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > Post SE-0067 FloatingPoint provides the usual global operators, as well as > a single global function: > > func sqrt(_: T) -> T > > It seems out of place and lon

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

on Mon Jul 11 2016, "L. Mihalkovic" wrote: > Regards > (From mobile) > >> On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> on Sun Jul 10 2016, Jasdev Singh wrote: >>> >>> Hey Swift Evolution! >>> >>> Drafted up a small proposal that harmonizes the use of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 11, 2016, at 00:50, Tino Heth via swift-evolution > wrote: > > >> In the implementation of the subclass, there has to be a call to one of the >> superclass's initializers. If all of the superclass’s initializers are >> non-public, then there’s no way to write your own initializer. (

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> on Wed Jul 06 2016, Tim Vermeulenwrote: > > > This is a follow up from this swift-users thread: > > https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html > > > > As it stands, RangeReplaceableCollection requires an implementation > > for init(), which is used in the de

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

2016/07/12 6:08、Jordan Rose via swift-evolution のメッセージ: > >> On Jul 11, 2016, at 04:34, Tino Heth <2...@gmx.de> wrote: >> >> I haven't read the whole Library Evolution document, but one important part >> is written right at the top: >> >>> This model is largely not of interest to libraries t

[swift-evolution] [pitch] remove global sqrt

Post SE-0067 FloatingPoint provides the usual global operators, as well as a single global function: func sqrt(_: T) -> T It seems out of place and lonely, and it would be nice if we can keep the default members of the global namespace to a minimum. I’d like to suggest removing this gl

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

-1 On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://githu

Re: [swift-evolution] Addition of a standardError OutputStream

It makes some sense: - Each process has its own Input/Output/Error streams. - Processes are piped through their streams. - C# has `StandardError`, `StandardInput`, `StandardOutput` properties on the `Process` class. On the other hand: - Java has them defined on `System` - Python is very similar

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 11, 2016, at 04:34, Tino Heth <2...@gmx.de> wrote: > > I haven't read the whole Library Evolution document, but one important part > is written right at the top: > >> This model is largely not of interest to libraries that are bundled with >> their clients (distribution via source, st

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

Regards (From mobile) > On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Sun Jul 10 2016, Jasdev Singh wrote: >> >> Hey Swift Evolution! >> >> Drafted up a small proposal that harmonizes the use of static functions and >> static function properties in appro

Re: [swift-evolution] [Pitch] Extending Swift Literals

> Right. I think if these things turn out to be sufficiently universal, I'd > want full canonical types and not just literals from Swift. +1 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 11, 2016, at 08:13, Leonardo Pessoa wrote: > > Jean, given this proposal it will be possible if the developer of the > library intends so. You'll have to have unsealed classes to be able to > subclass them and unsealed methods so you can override. It is possible > to just allow subclass

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> Le 11 juil. 2016 à 17:43, Jordan Rose a écrit : > > >> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas wrote: >> >> Just a though, but why sealed classes have to be completely unsubclassable ? >> >> Wouldn't it be possible to allow the user to subclass sealed class, but deny >> overriding of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Regards (From mobile) > On Jul 11, 2016, at 9:43 PM, Tony Allevato via swift-evolution > wrote: > >> On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner wrote: >> Hello Swift community, >> >> The review of "SE-0117: Default classes to be non-subclassable publicly" >> begins now and runs through Jul

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 11, 2016, at 11:16, Goffredo Marocchi wrote: > > So either open by default and sealed optionally or sealed by default and no > escape hatch? I think there are two separate decisions in here: - Open by default or sealed by default? - If sealed, can the seal be broken by clients? Thes

Re: [swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

> On 11 Jul 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > > > on Sat Jul 09 2016, Karl > wrote: > >>> On 8 Jul 2016, at 03:18, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Thu Jul 07 2016, Haravikk wrote: >>> >> > On

Re: [swift-evolution] Change subscripts to use colons

I've added one of my original points to the motivation section: ‘[The arrow] implies that subscripts have the full capabilities of functions, such as the ability to throw. If throwing functionality were to be added to accessors, it is likely the specific get/set accessor would be annotated. In

Re: [swift-evolution] Addition of a standardError OutputStream

Sorry, I don't really see how these are related to "process". Can you explain? On Mon, Jul 11, 2016 at 15:08 Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > `Process` might be a good place for namespacing these. You'll also note > that `print` can take an OutputStream to m

Re: [swift-evolution] Addition of a standardError OutputStream

`Process` might be a good place for namespacing these. You'll also note that `print` can take an OutputStream to make this even more idiomatic. Straw man example at https://gist.github.com/zwaldowski/4ed2fd48da2af3193b0cbd3ec1883c9d. Cheers! Zachary Waldowski z...@waldowski.me On Mon, Jul

Re: [swift-evolution] Change subscripts to use colons

I've written up a draft proposal, suggestions or improvements are welcome, especially relating to the title. __Change subscript declarations to use a colon__ --Introduction-- Currently, subscript declarations follow the following model: subscript(externalName internalName: ParamType) -> Ele

Re: [swift-evolution] Addition of a standardError OutputStream

You're right. It's at least tricky, if not currently impossible. I take it back then. I'd be happy with a `StandardStream` type (though I'd advocate, in the spirit of Swiftiness, to have it spelled out), with static `output` and `error`. This might be one of those rare cases where a reference type

  1   2   >