Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

To bring a little bit more context: I copied this Regex library in my project which had StringLiteralConvertible and implemented the pattern matching operator and all of a sudden, ALL init(rawValue: String) calls of completely unrelated enums started returning unexpected values. If I did not

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

>Possible solution: if you want a new protocol adoption to map to some existing >method or property then you must explicitly write that. You can't just adopt >the protocol in an empty extension. > >extension Int: BoundedType { >static var min = Int.min >static var max =

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> The pattern might exist for some existing classes or structs but it might > still be useful for new classes or even for some existing ones to provide a > default implementation. I agree. It could be very useful in certain circumstances, and I agree that any proposal that made this no longer

Re: [swift-evolution] Rename "guard" to "unless"

Hi James, “guard" is not the opposite of “if”. From the Swift book: “You use a guard statement to require that a condition must be true in order for the code after the guard statement to be executed.” So, unlike “unless”, a “guard" statement must provide an “early exit” in its else clause

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

You're quite right: in the worst case, the number of protocols you would need would be linear to the number of methods. It's not the best, I will concede. It does seem to be rather the "Swifty" way, though. At least, if we follow the example of the Swift standard library, it's not discouraged.

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Taking inspiration from syntax used for methods in classes that override >> methods in superclasses, require methods that override dynamically >> dispatched default implementations

Re: [swift-evolution] ternary operator ?: suggestion

Really not a fan of the idea of bloating the ternary operator out to deal with more cases. That’s what we already have switch and enum for. -jcr ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> On Jan 6, 2016, at 3:48 AM, Greg Parker via swift-evolution > wrote: > >> >> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Taking inspiration from syntax used for methods in classes that override

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

Hi all, since you mentioned: > Individuals or teams that feel that explicit “self.” is beneficial for their own code bases can enforce such a coding convention via tooling with the status quo. Are there any existing tools that already do that? I was hoping for a compiler flag where one could

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

I'm starting to understand. The implementation of RawRepresentable's probably looks like this: init?(rawValue: String) { switch rawValue { case "firstValue": self = .FirstCase case "secondValue": self = .SecondCase default: return nil } } In that case (no pun intended), the

Re: [swift-evolution] ternary operator ?: suggestion

I can't stop fiddling around with this... so here's another minor variation. My new new favourite, if we're doubling down on the ternary. We could start with Paul's ternary example... but it seems more in keeping to me, with the existing ternary, to use a colon as a separator. If we do that, an

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

You can probably use SwiftLint (https://github.com/realm/SwiftLint) and create a new rule. On Wed, Jan 6, 2016 at 9:17 AM, Honza Dvorsky via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > since you mentioned: > > Individuals or teams that feel that explicit “self.” is

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

+1 My sentiments exactly. As I was catching up on this thread, this was almost exactly the syntax I was already considering mentioning when I encountered Erica's reply. I don't know whether it will meet all requirements; however, from a readability perspective in both declarations and

Re: [swift-evolution] Type Safe Algorithms

There are lots of people who had an idea like this one, the latest just yesterday, where the other threads had been collected: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005353.html

Re: [swift-evolution] STDLibs

Big +1 from me. Rust's docs do this well too across trait implementations. On Wed, Jan 6, 2016 at 5:43 AM, James Campbell via swift-evolution < swift-evolution@swift.org> wrote: > Is there a way of improving the documentation and hosting it on Swift > instead of Apple ? > > Currently the Array

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On Jan 6, 2016, at 3:01 AM, Goffredo Marocchi via swift-evolution > wrote: > > while it is nice at first to have a type that adapts to the device word size > it runs on, I prefer to always have an explicit accuracy guarantee than > worrying about my CGFloat code

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 11:47 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution >> wrote: >> >> >>> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >>>

Re: [swift-evolution] About the PermutationGenerator

I've bounced this idea off of Dave and Dmitri internally, so might as well put it out publicly: In Magic DWIM Swift, there would only be two types that you'd ever conform to: a destructive iteration type (today's "Generator"), and a multi-pass indexed type (today's "Collection"). Some

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

Thanks Trent, I created an issue an there seems to be will to add it as an opt-in rule: https://github.com/realm/SwiftLint/issues/321 Greg and Doug, thanks for the details, I didn't realize that there aren't any language flags yet. In that case, I agree that moving this responsibility to a tool

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Jan 5, 2016, at 16:43 , Kevin Ballard wrote: > > On Tue, Jan 5, 2016, at 03:43 PM, Jordan Rose wrote: >> >>> On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution >>> > wrote: >>> On Jan 2,

Re: [swift-evolution] Explicity Size Clipping

I don't understand. Can you show a code example? Félix > Le 6 janv. 2016 à 13:02:43, James Campbell via swift-evolution > a écrit : > > I have a overloaded method for a protocol that takes an Int or double. > > I have an issue with swift calling the Int version

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution > wrote: > > >> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >> wrote: >> >> I remember this being discussed in the conversation about this proposal and >>

[swift-evolution] Explicity Size Clipping

I have a overloaded method for a protocol that takes an Int or double. I have an issue with swift calling the Int version when passing in a UInt32 . Ideally I would prefer the compiler to detect I am about to do something which will cause an overflow and throw an error. I would then have to

Re: [swift-evolution] removeFirst, optional equiviliant

Hi James, I believe this code already handles empty array scenario by failing if the precondition is not met. Or do you have something else in mind? max > On Jan 6, 2016, at 9:36 AM,

Re: [swift-evolution] removeFirst, optional equiviliant

What I mean't is it would be great is if it was a native swift error :) so we could use try? syntax. On Wed, Jan 6, 2016 at 6:32 PM, Max Moiseev wrote: > Hi James, > > I believe this code >

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On Jan 6, 2016, at 12:01 AM, Goffredo Marocchi wrote: > > Hello Chris, > > When dealing with floating point values, wouldn't it be in our best interest > to always be very specific about the accuracy of the floating point type > variables we use regardless of the device

Re: [swift-evolution] STDLibs

Chris do you think there is scope for this ? On Wed, Jan 6, 2016 at 2:38 PM, Trent Nadeau wrote: > Big +1 from me. Rust's docs do this well too across trait implementations. > > On Wed, Jan 6, 2016 at 5:43 AM, James Campbell via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

On Jan 5, 2016, at 4:09 PM, Jordan Rose via swift-evolution wrote: >> We have some declaration modifiers (e.g., access-control modifiers) and >> attributes (e.g., availability) that distribute in this manner from the >> extension to its members. My only hesitation

Re: [swift-evolution] STDLibs

This is a complicated topic, I’d suggest asking on swift-users or swift-dev since it isn’t related to language evolution. -Chris > On Jan 6, 2016, at 10:47 AM, James Campbell via swift-evolution > wrote: > > Chris do you think there is scope for this ? > > On

Re: [swift-evolution] STDLibs

Have you stopped by swiftdoc.org recently? :) -- Erica > On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution > wrote: > > Is there a way of improving the documentation and hosting it on Swift instead > of Apple ? > > Currently

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

> On Jan 5, 2016, at 10:57 AM, Dennis Lysenko > wrote: > > Chris, interesting tidbit. I wasn't aware of that. Is sourcekit considered to > be within the scope of the swift-evolution mailing list? No, it would be better to discuss it on swift-dev. -Chris

Re: [swift-evolution] About the PermutationGenerator

Thank you for this. Also, the book states: "SequenceType makes no requirement on conforming types regarding whether they will be destructively "consumed" by iteration. To ensure non-destructive iteration, constrain your sequence to CollectionType." Your magic DWIM Swift has generators (you

Re: [swift-evolution] ternary operator ?: suggestion

To point 1: I agree it needs a new name, I came up with the “demux expression” but maybe there is a better name. To point 2: Taking a more complex example which uses _ adapted from the swift book. The original switch somePoint { case (0, 0): print("(0, 0) is at the origin") case (_, 0):

Re: [swift-evolution] [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

> On Jan 5, 2016, at 9:28 AM, David Hart via swift-users > wrote: > > How is it that Swift allows code like this: > > struct Sneaky: StringLiteralConvertible { > init(stringLiteral value: String) {} > init(extendedGraphemeClusterLiteral value: String) {} >

Re: [swift-evolution] STDLibs

I did but it redirects elsewhere now :S On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun wrote: > Have you stopped by swiftdoc.org recently? > > :) > > -- Erica > > > On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution < >

Re: [swift-evolution] STDLibs

> On Jan 6, 2016, at 11:06 AM, James Campbell via swift-evolution > wrote: > > I did but it redirects elsewhere now :S It’s “swiftdoc.org”, not “swiftdocs.org” as in the link. - Doug > > On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun

Re: [swift-evolution] Explicity Size Clipping

This is the full code: // // Box.swift // Project // // Created by James Campbell on 06/01/2016. // // // This File implements the Box protocol for Type Safe Alogrithm Types and other useful things. import Foundation //MARK:- Box protocol Box: CustomStringConvertible,

Re: [swift-evolution] removeFirst, optional equiviliant

I personally would love to have it as optional behaviour. Not sure when you would ever need it to be non optional ? On Wed, Jan 6, 2016 at 6:54 PM, Max Moiseev wrote: > Ahhh, right. > > I believe the thinking here is that since this is an avoidable error, it > should be

Re: [swift-evolution] Explicity Size Clipping

That last line, the value inside the Degree struct should be a Int created from a UInt32 On Wed, Jan 6, 2016 at 7:08 PM, James Campbell wrote: > This is the full code: > > // > > // Box.swift > > // Project > > // > > // Created by James Campbell on 06/01/2016. > > // > >

Re: [swift-evolution] Explicity Size Clipping

I either don't understand or can't reproduce the issue. This code: > class Box { > let value: Int > > init(value: Int) { > self.value = value > } > } > > let test: UInt32 = 4 > let box = Box(value: test) does not compile ("foo.swift:10:22: error: cannot

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 8:56 AM, Greg Parker via swift-evolution > wrote: > >> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >> > wrote: >> >> I remember this being discussed in the

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

On Wed, Jan 6, 2016 at 2:18 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > > I just spent a half hour last night debugging an issue that turned out to > be caused by something getting written to a property which I thought was > being written to a local variable, due

[swift-evolution] [Proposal]: Rectangles and other common structures.

Sorry if this is a repeat, but I’d like to suggest promoting certain structs from Foundation to the Swift standard library. As an OS X and iOS developer, it sometimes seems that I work with [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or String. I’d love to see

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

Do you use them a lot outside of a Cocoa/UIKit context? Félix > Le 6 janv. 2016 à 00:08:35, John Randolph via swift-evolution > a écrit : > > Sorry if this is a repeat, but I’d like to suggest promoting certain structs > from Foundation to the Swift standard

Re: [swift-evolution] ternary operator ?: suggestion

Just a couple of thoughts swirling in my brain. 1. Ternary means : composed of three parts …. if we add case functionality, it no longer is a ternary and should be renamed (ex : nil coalescing … was used instead of calling it a ternary optional). Would love to hear thoughts on what names it

[swift-evolution] removeFirst, optional equiviliant

If you call removeFirst and the array is empty it would be great if it was optional so it could return nil or at least it threw an error so you could handle that case. --  Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list

Re: [swift-evolution] Support for newtype feature/typesafe calculations

I've managed to implement this already in the language with a few ugly corners due to the lack of generic protocols. I created a protocol based on Box (https://github.com/robrix/Box/) which works really well. I have extended this to handle certain special protocols like Equatable so you can do

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

Hi, Could you point to what Regex code are you using? You mention you copy some library but don't provide the original source. On Wed, Jan 6, 2016 at 9:12 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: > I'm starting to understand. The implementation of RawRepresentable's

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Hello Chris, When dealing with floating point values, wouldn't it be in our best interest to always be very specific about the accuracy of the floating point type variables we use regardless of the device it runs on? This is the biggest problem I had with CGFloat: while it is nice at first to

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

(this is mostly a repost of a message I sent to the "[draft]" thread for this proposal, with some light editing to better match terminology in the proposal) *What is your evaluation of the proposal?* I like this proposal. I think it will bring some much-needed ease-of-use. I have reservations

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: > > I find it surprising that you key the initialization of 'var's based on > whether their setter is visible or not. Initialization is not the same as > setting, and memberwise initializers within the definition have private >

Re: [swift-evolution] removeFirst, optional equiviliant

Yeah I was using this for a LIFO type system :) glad to know there is a method for this. On Thu, Jan 7, 2016 at 12:09 AM, Dave Abrahams wrote: > > On Jan 6, 2016, at 3:48 PM, Jacob Bandes-Storch > wrote: > > Whoops, I meant append()/popFirst. That is,

[swift-evolution] SignedNumberType

What is the purpose of this type ? Why don't we have UnsignedNumberType --  Wizard ja...@supmenow.com +44 7523 279 698 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

I like Greg Parkers suggestion, if the extension is of a type that is not part of the project/library that is being developed then you don't need override. This would allow after-the-fact extensions to library and third-party structure/classes. It is also not confusing to human or compiler, since

Re: [swift-evolution] removeFirst, optional equiviliant

> On Jan 6, 2016, at 3:48 PM, Jacob Bandes-Storch wrote: > > Whoops, I meant append()/popFirst. That is, even for a single-ended queue, > you'll use one "first" operation (less efficient) and one "last" operation. No, a single-ended queue is a stack. You can use append

[swift-evolution] [Review] SE-0010 Add StaticString.UnicodeScalarView

Hello Swift community, The review of SE-0010 "Add StaticString.UnicodeScalarView" begins now and runs through Friday, January 8th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0010-add-staticstring-unicodescalarview.md Reviews are an

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Hi Matthew, Thanks for the explanation. Before getting into a deeper discussion, I'd like to try to enumerate the reasons for adding the placeholder as I understand them: 1. Add clarity by visually distinguishing memberwise initializers from normal initializers. 2. Introduce a

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Meta: most reviews have the review dates in the Status field of their document, this one doesn't. I was a little confused at first. For the proposal itself: # What is your evaluation of the proposal? +1 # Is the problem being addressed significant enough to warrant a change to Swift? Yes, I

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "Flexible Memberwise Initialization" begins now and runs > through January 10th. The proposal is available here: > > >

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> I don't like this solution because the compiler produces poor error > messages. It says that the type that implements the protocol doesn't conform > to the protocol in all three cases described below. Whereas if override were > required the compiler would say one of: I completely agree that the

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

1. What is your evaluation of the proposal? I think the proposal has merit. It seeks to clarify a possible confusing issue. I’m late to this issue, however, and perhaps because I read through everything in one go, but the keyword that came to me was “conformancetype”. We’re talking protocols

Re: [swift-evolution] [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

> On Jan 6, 2016, at 2:31 PM, David Hart wrote: > > I can file those bugs. Would it be beneficial if I also created failing unit > tests? > David. Definitely. Thanks for uncovering these issues. -Joe ___ swift-evolution mailing

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Here is an expanded proposal for the syntax for a Scala style memberwise syntax and equivalent code, specification is via an example rather than formal syntax since this is easier to follow. Note it is like Scala’s syntax but it is ‘Swiftified” (in particular still retains `init` keyword).

[swift-evolution] Improve Number Type

There is a number of deficiencies with Swift and Numbers. Especially when trying to be clever with generics. - The API exposes built in types like`BuiltIn.Word` as the return type of some APIs but there is no way to use said types. - We have a Float and a Float80. Float and Doubles can't be

Re: [swift-evolution] SignedNumberType

The numeric protocols were not really designed; their main purpose is currently to facilitate some very weak code sharing in the standard library. We’re currently working on fixing that, though, as I noted in other messages. > On Jan 6, 2016, at 3:00 PM, James Campbell via swift-evolution >

Re: [swift-evolution] removeFirst, optional equiviliant

Whoops, I meant append()/popFirst. That is, even for a single-ended queue, you'll use one "first" operation (less efficient) and one "last" operation. On Wed, Jan 6, 2016 at 3:47 PM, Dave Abrahams wrote: > > On Jan 6, 2016, at 3:42 PM, Jacob Bandes-Storch

Re: [swift-evolution] SignedNumberType

Great to hear that there is a fix on the way. On Thursday, 7 January 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > The numeric protocols were not really designed; their main purpose is > currently to facilitate some very weak code sharing in the standard >

Re: [swift-evolution] ternary operator ?: suggestion

Made a mistake on first example underscore should not have been quoted: let resultString = someCharacter ?( "a", "e", "i", "o", “u”: "\(someCharacter) is a vowel" "b", "c", "d", "f", "g", "h", "j", "k", "l", “m”, "n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z”:

Re: [swift-evolution] removeFirst, optional equiviliant

> On Jan 6, 2016, at 3:42 PM, Jacob Bandes-Storch wrote: > > Oops, I forgot this existed. > > I'm assuming you're recommending popLast for performance reasons? > Unfortunately, for a …double-ended… > queue, you'll need either insertAtIndex(0)/popLast or append()/popLast

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

Comments in-line below. On Thursday, 7 January 2016, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > > Another option might be to allow imported definitions to be used by a > > conformance without the `override` marking to support retroactive > modeling > > while requiring

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 7:05 PM, David Owens II via swift-evolution > wrote: > > -1 for me. > >> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution >> > wrote: >> >> Hello Swift community, >> >>

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Sent from my iPad > On Jan 6, 2016, at 7:47 PM, Joe Groff wrote: > > >>> On Jan 6, 2016, at 5:23 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 6:31 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: >> >> >>> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: >>> >>> On Jan 6, 2016,

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Yes I did mess up the translation, that will teach me to do it at night on an iPad (therefore no compiler). The correct translation is: Types and let's needed for example: public class SuperType { init(_: SPType) {} } public struct SPType {} public struct PPType {}

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

I support this, not because I find NS- and CG- geometric structs confusing. I support it because I'm hoping Swift library versions would be generic. I would be very glad to see us get *Rect* or *Point* as part of the standard library. On Wed, Jan 6, 2016 at 9:32 PM, John Randolph via

Re: [swift-evolution] ternary operator ?: suggestion

agreed that bar might not work > On Jan 6, 2016, at 9:35 PM, Alex Popov wrote: > > You're right Charles, the confusion with the OR operator is something I > neglected to mention (despite noticing it) because of my own preference. > However, I would like some kind of

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: > > >> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: >> >> >>> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: >>> >>> I find it surprising that you key the

Re: [swift-evolution] ternary operator ?: suggestion

Alex, We know, from the traditional ternary, that a colon is going to satisfy the requirements of a separator, even when we want to chain. Is this the case with bar "|"? To me, this doesn't bode well let a = b ? 2 : 3 | 4 : 5 | _ : -1 Above, are we talking about a result of "3

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of "Flexible Memberwise

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: > > >> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: >> >> I find it surprising that you key the initialization of 'var's based on >> whether their setter is visible or not. Initialization is not

Re: [swift-evolution] ternary operator ?: suggestion

multiary is not a natural and easy expression to pronounce. ternary was likely used originally because they could not think of something better - but at least it is easy on the tongue…. [composed of 3 parts] regardless of syntax - maybe just call it a “match expression”. > On 2016-01-07,

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> * What is your evaluation of the proposal? I am generally in favor. I enjoy the current memberwise initializer feature and would like to see it become useful in more cases. One thing I don't like (and was intending to discuss—the review snuck up on me) is the keyword `memberwise`. This

Re: [swift-evolution] ternary operator ?: suggestion

Hi Paul, My opinion, atm, is that ":" as a separator is the best solution. True, it's not *Swift-like*, but neither is the existing ternary, which Chris wants to keep. On then other hand, "colon as separator" is extremely *ternary-like*. So benefits of "colon as separator" as I see them: -

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

The point is that without the requirement of both final and override the compiler doesn't know in detail what the problem is; just that there is a problem, it doesn't have enough information (it doesn't know the programmers intention - override and final clarify that intension). That is

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Jan 6, 2016, at 8:43 PM, Joe Groff wrote: > > >> On Jan 6, 2016, at 6:31 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: > On

Re: [swift-evolution] ternary operator ?: suggestion

> I see what you are trying to do, because of the colon being both used for switch cases and > separators for the ternary and so there needs to be a new character for each case. > I am not sure that putting colons between each case is really necessary though. Most of us (including you and I) like

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me including the preference for "associated" instead of "associatedtype" -Thorsten Am 03.01.2016 um 19:10 schrieb Alex Migicovsky via swift-evolution : >> * What is your evaluation of the proposal? > > I think the proposal is great. The only thing I’d

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

On Jan 6, 2016, at 7:21 PM, Matthew Johnson wrote: > On Jan 6, 2016, at 6:39 PM, Alex Johnson > wrote: > > Hi Matthew, > > Thanks for the explanation. > > Before getting into a deeper discussion, I'd like to

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 19:07 , Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 6, 2016, at 8:43 PM, Joe Groff > wrote: > >> >>> On Jan 6, 2016, at 6:31 PM, Matthew Johnson

Re: [swift-evolution] ternary operator ?: suggestion

I like the bar `|` variation, but I do think the control value should be out front, otherwise the ? reads as an optional to my mind, whereas the former comes across as the beginning of a ternary (which this is effectively an extension of). The bar variation feels Haskell-y in a satisfying way,

Re: [swift-evolution] ternary operator ?: suggestion

You're right Charles, the confusion with the OR operator is something I neglected to mention (despite noticing it) because of my own preference.  However, I would like some kind of explicit separator between cases. If we're unwilling to reuse the `case` keyword, I hope commas will be enforced. 

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 6:39 PM, Félix Cloutier via swift-evolution > wrote: > > Meta: most reviews have the review dates in the Status field of their > document, this one doesn't. I was a little confused at first. > > For the proposal itself: > > # What is your

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 4:52 PM, Howard Lovatt wrote: > > Here is an expanded proposal for the syntax for a Scala style memberwise > syntax and equivalent code, specification is via an example rather than > formal syntax since this is easier to follow. Note it is like

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Sent from my iPad > On Jan 6, 2016, at 8:46 PM, Dave Abrahams wrote: > > > > Sent from my moss-covered three-handled family gradunza > >> On Jan 6, 2016, at 5:47 PM, Joe Groff wrote: >> >> On Jan 6, 2016, at 5:23 PM, Matthew Johnson via

Re: [swift-evolution] ternary operator ?: suggestion

> multiary is not a natural and easy expression to pronounce. I'd be fine with "match expression". Also fine with "multary" (no "i"), which is apparently a common alternative to "multiary." If we use the "colon as separator" version of this proposal, which uses the existing syntax for a ternary,

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

> On Jan 5, 2016, at 10:10 PM, Brent Royal-Gordon > wrote: > >> As an OS X and iOS developer, it sometimes seems that I work with >> [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or >> String. I’d love to see Swift’s standard library

Re: [swift-evolution] [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

I can file those bugs. Would it be beneficial if I also created failing unit tests? David. > On 06 Jan 2016, at 20:05, Joe Groff wrote: > >> >> On Jan 5, 2016, at 9:28 AM, David Hart via swift-users >> > wrote: >> >> How

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

It seems no different to me than when "instancetype" was added to Objective C (though, that doesn't say anything for the 'Swiftiness' of it). Ross On Wed, Jan 6, 2016 at 9:08 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > I'm sure we're just bikeshedding at

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> On Jan 2, 2016, at 10:38 PM, Douglas Gregor via swift-evolution > wrote: > > * What is your evaluation of the proposal? This definitely makes the two concepts much more easy to understand. Overloading the meanings is confusing. Separating them helps a lot.

  1   2   >