Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

I think this is a good idea - the implementation of Any ( = Any<>) should not be specified to be a typealias. (And this would resolve the idea Colin brought up.) To David's points (to avoid clogging up the list): - 'Any' is still valid, and has the same meaning as it did before. - 'Any<>'

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

> Swift 3.0 focuses on making breaking changes that prepare the way for > features to be introduced in future releases. In that spirit, I would like to > solicit feedback on a very simple proposal: renaming 'protocol<>' to 'Any<>', > as described in the 'Completing Generics' manifesto. > > The

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

I’m a fan (mostly because I think it helps existential types, which have blocked quite a few library projects of mine), but I do have a few questions about the impact of the proposal - I assume ‘Any' is still valid? - In that case, would 'Any<>' be equivalent to ‘Any’, or a warning/error? -

[swift-evolution] [Pitch] Rename protocol<> to Any<>

Hello all, Swift 3.0 focuses on making breaking changes that prepare the way for features to be introduced in future releases. In that spirit, I would like to solicit feedback on a very simple proposal: renaming 'protocol<>' to 'Any<>', as described in the 'Completing Generics' manifesto. The

[swift-evolution] [Accepted] SE-0081: Move where clause to end of declaration

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md Hello Swift Community, The review of SE-0081: "Move where clause to end of declaration" ran from May 10...16, 2016. The proposal is *accepted* for Swift 3. The feedback on this proposal

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Put me firmly in the pro-warning camp. If enforcing manual synthesis of ivars (something I never understood the brouhaha about) warranted a warning flag in clang, I think requiring self should at least merit consideration. It certainly has a much greater potential for bugs than automatic ivar

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Geeat solution! Thanks to Nicola for posting it! > Am 14.05.2016 um 16:35 schrieb Matthew Johnson via swift-evolution > : > > >> On May 14, 2016, at 12:55 AM, Nicola Salmoria via swift-evolution >> wrote: >> >> Matthew Johnson via

[swift-evolution] [Rejected] SE-0041: Updating Protocol Naming Conventions for Conversions

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md Hello Swift Community, The review of SE-0041: "Updating Protocol Naming Conventions for Conversions" ran from May 10...16, 2016. The proposal is *rejected* for Swift 3. The

[swift-evolution] [Accepted] SE-0075: Adding a Build Configuration Import Test

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md Hello Swift Community, The review of SE-0075: "Adding a Build Configuration Import Test" ran from May 10…16, 2016. The proposal is *accepted* for Swift 3. The community and core team are both

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Thanks for the link, I'll definitely keep my eye on it, though since there are two large camps siding with either side, I don't see the harm making this proposal an optional warning of the compiler that would be off by default and those wanting to stay on the safe side would enable this and get

Re: [swift-evolution] Proposal SE-0009 Reconsideration

That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler. There is an open bug on SwiftLint

Re: [swift-evolution] StringInterpolationConvertible and StringLiteralConvertible inheritance

> StringInterpolationConvertible inheritance of StringLiteralConvertible would > allow "static-string" and \(string-expression) segments to be differentiated. > > /// For example, `"\(paragraph)" as HTML` would invoke: > /// > /// HTML.init(stringInterpolation: > /// HTML.init(stringLiteral:

Re: [swift-evolution] [Proposal] Switch Let

You can already do something pretty close to what you want: enum Barcode { case UPCA(numberSystem: Int, manufacturer: Int, product: Int, check: Int) case QRCode(productCode: String) } var productBarcode = Barcode.UPCA(numberSystem: 8, manufacturer: 85909, product: 51226, check: 3)

[swift-evolution] [Proposal] Switch Let

Hi I will like to make the proposal to allow a switch let, similar to a if let, this will avoid having to repeat every variable name enum Barcode { case UPCA(Int, Int, Int, Int) case QRCode(String) } var productBarcode = Barcode.UPCA(8, 85909, 51226, 3) //current: switch productBarcode

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Oh yep, I accidentally read that section as ‘Alternatives Considered’. I still find this a little bit of a hack, so I hope this approach doesn’t get used too much, certainly not in the standard library. Is this only useful for factory or other static methods? It would just be a shame to see

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 18, 2016, at 9:57 PM, Patrick Smith wrote: > > I think the distinction between StaticSelf and Self will be very confusing to > newcomers. > > So the only reason why we must use StaticSelf instead of Self here is because > we want NSURL to

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Optional is already CustomStringConvertible. Again, this was done on purpose (that's not an argument to keep it this way, though). Source On Wed, May 18, 2016 at 6:33 PM David Sweeris via swift-evolution <

Re: [swift-evolution] RFC: didset and willset

I really don't want didSet and willSet to be changed. Will changing them make them easier to tell apart from each other? I don't think so. I think it'll only make it slightly harder, now that there isn't a easily-identifiable visual cue that groups "didSet" and "willSet" on one hand, and "set"

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I think the distinction between StaticSelf and Self will be very confusing to newcomers. So the only reason why we must use StaticSelf instead of Self here is because we want NSURL to conform, and it isn’t final? protocol StringCreatable { static func createWithString(s: String) ->

Re: [swift-evolution] RFC: didset and willset

I prefer camelCase but if it's inconsistent to the current Swift then I guess a review is needed. I would like to add though that a small change of letter case that will break Swift just because it feels inconsistent is a bit over the top. It needs to be reviewed properly. I'm also against

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

> * What is your evaluation of the proposal? -1. Too early to optimize this. I would also be opposed to renaming didSet/willSet to lowercased preemptively because of the sake of renaming. I think property behaviors should declare their own naming and syntax conventions (and be accepted

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Perhaps a better approach to the shadow variables problem is to enable the objc compiler flag -Wshadow to be available in Swift. In the same way a "requiring self" compiler flag should help enforce self on the programer by always showing a warning when the flag is on. > On May 18,

Re: [swift-evolution] RFC: didset and willset

I like them camelCase. > On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 18, 2016, at 2:56 PM, Krystof Vasa wrote: >> >> Not to mention @NSApplicationMain, @NSManaged, ... >> >> I'd personally keep it

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

We could make Optional conform to CustomStringConvertible: var description: String { switch self { case .some(let x): return "\(x)" case .none: return "\(Wrapped.self)?.none" } } - Dave Sweeris > On May 18, 2016, at 15:56, Michael Peternell via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

On 5/18/2016 10:21 AM, Tony Allevato wrote: > On Wed, May 18, 2016 at 12:10 AM Brent Royal-Gordon via > swift-evolution > wrote: > > ... > > What I'm suggesting is that, on unary operators, Swift require > either the

Re: [swift-evolution] RFC: didset and willset

Agreed. Personally I prefer willSet and didSet, but consistency of rules is higher priority. +1. > On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution > wrote: > > didSet and willSet remain outliers in the general rule of conjoined lowercase > keywords. Is

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

* What is your evaluation of the proposal? I’m -1 on this. The only motivation given for the proposal is: > Swift's rule for attribues/keywords is that keywords usually modify type of > variable; attributes do not. Chris Lattner has [refuted

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

> On May 18, 2016, at 10:51 AM, David Hart wrote: > > Could you show me an example of a fictional EDSL that gets better with > newline separated lists? I’ll do better than that. I’ll show and example of a real EDSL I implemented in Ruby in the early days of iOS. It was

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

Mixed; there are very good ideas here but combined in IMHO some questionably-strict ways. I understand that starting small and extending later is preferable, and I understand the Swift 3 situation. In favor of these: - allowing static methods to have “operator names” - deprecating operator

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

-1. Optional(foo) better depicts the actual type (it's an options string, after all). If you're not happy with it, just use the nil coalescing operator such as "\(foo ?? "")". This is from the same series of proposals as implicit casting - there are reasons it's done the way it is. On Wed, May

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

+1, personally I have taken to using `x+"str"+y` instead of `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if I do this accidentally. But I do see the appeal of being able to print("the data: \(data)") for simple use cases. Didn't someone earlier propose some

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

> On May 18, 2016, at 12:51 PM, Joe Groff wrote: > >>> I thought about this, but { $0 } is already a fairly compact way to express >>> the identity function. >> >> It is, but I worry a bit about the core team's tendency to say "Oh, just use >> a closure" whenever something

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

+1 from me as well. All these “Optional(foo)” things showing up in user-facing strings are a pain, and since they don’t show up until runtime, it’s really easy to miss them. Charles > On May 18, 2016, at 1:50 PM, Krystof Vasa via swift-evolution > wrote: > > The

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> On May 17, 2016, at 8:32 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0089: Renaming String.init(_: T)" begins now and runs > through May 23. The proposal is available here: > > >

Re: [swift-evolution] Support for coding styles and "swift-format" tool

What I would like even more is editor support with this stuff. And I think the "swift-format" tool could probably help here too. I remember a time when we had problems with LF vs. CR vs. CRLF line endings. How did Sublime Text Edit (or any other sane editor) solve this issue? Do we all have to

Re: [swift-evolution] Enhanced existential types proposal discussion

Please excuse me for my horrible writing. I guess I’m to tired right now and write a ton strange sentences and typos. :/ Anyways, when the right time comes, I’ll fully support this feature. Any is defiantly worth being part of Swift. Good n8 everyone. --  Adrian Zubarev Sent with Airmail Am

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 2:20 PM Matthew Johnson wrote: > On May 18, 2016, at 4:06 PM, Tony Allevato wrote: > > On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> Personally, I find Rust’s

Re: [swift-evolution] Enhanced existential types proposal discussion

Okay I got it now, generics made my had spin. I also received no feedback on my proposal to that specific case, which I misunderstood. Thank you for clarifying that to me. That said it makes now sense to force the first requirement, which I dropped in my proposal.  I’d fix that tomorrow. I’m

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 18, 2016, at 4:17 PM, Austin Zheng via swift-evolution > wrote: > > I'm not sure what your objections actually are, but my responses are inline. Your responses are exactly what mine would be. For a second I was worried that I missed something when reading

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On 18 mai 2016, at 15:09, Xiaodi Wu via swift-evolution > wrote: > > > Yeah, also good points. Can I propose maybe another approach? > > ``` > T.operator(+, a, b) > T.operator(prefix: ++, a) > T.operator(postfix: ++, a) > ``` I like that this applies the

Re: [swift-evolution] RFC: didset and willset

> Am 18.05.2016 um 22:58 schrieb Josh Parmenter via swift-evolution > : > > I have a general preference for camelCase as well, but I would prefer > consistency in the language over my own personal preference. In fact, I wouldn't care much about the naming. But I

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 4:06 PM, Tony Allevato wrote: > > On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution > > wrote: > > Personally, I find Rust’s approach a bit ugly. And Tony makes a very

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 4:01 PM, Nicola Salmoria > wrote: > > > > On Wed, May 18, 2016 at 10:36 PM, Matthew Johnson > wrote: > >> On May 18, 2016, at 3:14 PM, Nicola Salmoria >

Re: [swift-evolution] Enhanced existential types proposal discussion

I'm not sure what your objections actually are, but my responses are inline. On Wed, May 18, 2016 at 1:57 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > So without any initial constraints how would one use this generic > function?? > > extension UIButton: ProtocolA

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 3:56 PM, Matthew Johnson wrote: > > On May 18, 2016, at 3:48 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Wed, May 18, 2016 at 3:37 PM, Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote:

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

`init(describing:)` make sense to me. I can see how it could be argued “well it looks like it calls the ‘description’ method of the argument, when it doesn’t, so this is poor naming”. However, `init(printing:)` looks like it has something to do with `print()`, when it doesn’t. ‘Print’ is a

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > Personally, I find Rust’s approach a bit ugly. And Tony makes a very good > point in the proposal that using words requires us to learn the word > associated with each operator. >

Re: [swift-evolution] RFC: didset and willset

Matthew's right. The first thing here is to define a consistent rule which takes no exceptions and then apply this rule to every existing or new keyword and attribute. On 18 May 2016 at 18:02, Matthew Johnson wrote: > >> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via

Re: [swift-evolution] RFC: didset and willset

> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I may be wrong but I don't remember any other case of a keyword in >> Swift composed of two or more words, so I believe these should be >> exceptions. > > `typealias` and

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> Am 18.05.2016 um 21:53 schrieb Goffredo Marocchi via swift-evolution > : > > The code you pasted really ought to print a warning out (allowing variable > shadowing without even a warning can lead to annoying bugs), a generation of > Swift developers will be

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 10:36 PM, Matthew Johnson wrote: > > On May 18, 2016, at 3:14 PM, Nicola Salmoria > wrote: > > > > On Wed, May 18, 2016 at 10:03 PM, Matthew Johnson > wrote: > >> >> On May 18, 2016, at 3:00 PM,

Re: [swift-evolution] RFC: didset and willset

> On May 18, 2016, at 3:53 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> didSet and willSet remain outliers in the general rule of conjoined >> lowercase keywords. Is there any support for bringing these outliers into >> the fold? > > I don't think we

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> Hello Swift community, > > The review of "SE-0091: Improving operator requirements in protocols" begins > now and runs through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > >

Re: [swift-evolution] RFC: didset and willset

> On May 18, 2016, at 2:56 PM, Krystof Vasa wrote: > > Not to mention @NSApplicationMain, @NSManaged, ... > > I'd personally keep it camelCase. > Those are sourced external to Swift. >> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution >>

Re: [swift-evolution] RFC: didset and willset

I have a general preference for camelCase as well, but I would prefer consistency in the language over my own personal preference. Best, Josh > On May 18, 2016, at 1:56 PM, Krystof Vasa via swift-evolution > wrote: > > Not to mention @NSApplicationMain, @NSManaged,

Re: [swift-evolution] Enhanced existential types proposal discussion

So without any initial constraints how would one use this generic function?? extension UIButton: ProtocolA {} let button = UIButton() let shadowedButton: ProtocolA = UIButton() // creates a set of a least one element if the generic type could be inferred func unionIfPossible(_ a: T, _ b:

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Well, I wouldn't deprecate them. Maybe it should print something different: the value itself if it is not nil, and "nil" otherwise? Or there may be an optional warning for this case. Or maybe both. But not just deprecate the feature altogether. It will make people use the "!" instead in

Re: [swift-evolution] RFC: didset and willset

Yeah I agree completely with this. They may be camel case with property behaviours, so best to keep them as is for now. > On 19 May 2016, at 6:53 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> didSet and willSet remain outliers in the general rule of

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 3:48 PM, Xiaodi Wu via swift-evolution > wrote: > > > > On Wed, May 18, 2016 at 3:37 PM, Nicola Salmoria via swift-evolution > > wrote: > > > On Wed, May 18, 2016 at 10:27 PM,

Re: [swift-evolution] RFC: didset and willset

Not to mention @NSApplicationMain, @NSManaged, ... I'd personally keep it camelCase. > On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution > wrote: > > Just some context: > > "We have a few conjoined keywords already (typealias, associatedtype, >

Re: [swift-evolution] RFC: didset and willset

> I may be wrong but I don't remember any other case of a keyword in > Swift composed of two or more words, so I believe these should be > exceptions. `typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be

Re: [swift-evolution] RFC: didset and willset

Just some context: "We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers" and "On it being a conjoined word, we

Re: [swift-evolution] RFC: didset and willset

> didSet and willSet remain outliers in the general rule of conjoined lowercase > keywords. Is there any support for bringing these outliers into the fold? I don't think we shouldn't touch these until we know what accessors on property behaviors are going to look like. We could very well change

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:37 PM Nicola Salmoria wrote: > On Wed, May 18, 2016 at 10:27 PM, Tony Allevato > wrote: > >> >> What I'm saying is, if you look at the Swift 3 branch of stdlib, global >> operator functions still do not have argument

Re: [swift-evolution] RFC: didset and willset

I may be wrong but I don't remember any other case of a keyword in Swift composed of two or more words, so I believe these should be exceptions. I would agree best to change these keywords for others consisting of only one word but I myself have no suggestion what those could be. Otherwise I'd

Re: [swift-evolution] RFC: didset and willset

+1 on not getting rid of willSet and didSet for sure! As for naming, it doesn’t bother me much either way, but I think lowercase makes sense with the direction everything else is going. l8r Sean > On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution >

Re: [swift-evolution] Proposal SE-0009 Reconsideration

> On May 18, 2016, at 1:43 PM, Krystof Vasa wrote: > > See my example with the tableView and the UITableViewDelegate on > UITableViewController. `if let x = x` isn't the usual case. The usual case is > that you have e.g. tableView instance on the class and a method that

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 3:37 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > > On Wed, May 18, 2016 at 10:27 PM, Tony Allevato > wrote: > >> On Wed, May 18, 2016 at 1:00 PM Nicola Salmoria < >> nicola.salmo...@gmail.com> wrote: >> >>> On Wed,

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

> Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > * What is your

Re: [swift-evolution] RFC: didset and willset

Hi Erica, "didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 10:27 PM, Tony Allevato wrote: > On Wed, May 18, 2016 at 1:00 PM Nicola Salmoria > wrote: > >> On Wed, May 18, 2016 at 8:03 PM, Tony Allevato >> wrote: >> >>> On Wed, May 18, 2016 at 10:02 AM Nicola

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 3:14 PM, Nicola Salmoria > wrote: > > > > On Wed, May 18, 2016 at 10:03 PM, Matthew Johnson > wrote: > >> On May 18, 2016, at 3:00 PM, Nicola Salmoria via swift-evolution >>

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> Hello Swift community, > > The review of "SE-0089: Renaming String.init(_: T)" begins now and runs > through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md > > * What is your

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On May 18, 2016, at 3:17 PM, Erica Sadun wrote: > >>> >>> The whole discussion started because ArrayLiteralConvertible meant "can be >>> initialized from Array literal", and not "can be converted to array >>> literal", which is what nearly everyone this was presented

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 18, 2016, at 3:15 PM, Adrian Zubarev via swift-evolution > wrote: > > So without any initial constraints how would one use this generic function?? > > extension UIButton: ProtocolA {} > > let button = UIButton() > let shadowedButton: ProtocolA = UIButton()

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 1:00 PM Nicola Salmoria wrote: > On Wed, May 18, 2016 at 8:03 PM, Tony Allevato > wrote: > >> On Wed, May 18, 2016 at 10:02 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > * What is

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

> The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May > 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md > > * What is your evaluation of the proposal? I have nothing against

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 18, 2016, at 11:30 AM, Austin Zheng wrote: > > I made heavy revisions to my proposal to reflect all the great feedback I got > from you and several other folks >

Re: [swift-evolution] Proposal: Finalization in protocol extensions and default implementations

That is exactly what I was thinking about back then when I posted this idea, but this doesn’t work, at least right now. I’m not sure if this will change if we’ll be forced to use `override` when there is a default implementation provided by the protocol. I’d hope for that behavior. Described

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

>> >> The whole discussion started because ArrayLiteralConvertible meant "can be >> initialized from Array literal", and not "can be converted to array >> literal", which is what nearly everyone this was presented to in an informal >> study thought it meant. >> > > That was not the genesis

Re: [swift-evolution] Pitch: Modify the meaning of IBOutlet to remove the ! from the type

The really nice thing about the "!" operator is that it is always explicit. Either in the variable declaration, or when unwrapping it with "!" or "if let". "@IBOutlet weak var"s should therefore really not introduce an implicit "!". It's just one character, and it's good to see that this is

Re: [swift-evolution] Enhanced existential types proposal discussion

So without any initial constraints how would one use this generic function?? extension UIButton: ProtocolA {} let button = UIButton() let shadowedButton: ProtocolA = UIButton() // creates a set of a least one element if the generic type could be inferred func unionIfPossible(_ a: T, _ b:

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

On Wed, May 18, 2016 at 10:03 PM, Matthew Johnson wrote: > > On May 18, 2016, at 3:00 PM, Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Wed, May 18, 2016 at 8:03 PM, Tony Allevato > wrote: > >> On Wed, May 18,

Re: [swift-evolution] [Pitch] Requiring special keyword to mark protocol implementation methods

Hi Vladmir! There is something very similar to this in C#. I like this but I'd like to enhance it a little bit. I don't think it's necessary to decorate protocol methods any further but some warnings by the compiler would be welcome, like when pushing a type to adopt a protocol through an

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On May 18, 2016, at 3:01 PM, Erica Sadun wrote: > > >> On May 18, 2016, at 1:58 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On May 18, 2016, at 1:52 PM, Brent Royal-Gordon >>> wrote: >>> > If

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 3:00 PM, Nicola Salmoria via swift-evolution > wrote: > > > > On Wed, May 18, 2016 at 8:03 PM, Tony Allevato > wrote: > On Wed, May 18, 2016 at 10:02 AM Nicola Salmoria via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On May 18, 2016, at 1:58 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 18, 2016, at 1:52 PM, Brent Royal-Gordon >> wrote: >> If we're doing this, I wonder if category 1 shouldn't just be `Convertible`. This

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

> On May 18, 2016, at 2:55 PM, Joe Groff wrote: > >> >> On May 18, 2016, at 12:54 PM, Matthew Johnson wrote: >> >> >>> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution >>> wrote: >>> >>> Currently, we parse a

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution > wrote: > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as' expression appears as part of > a comparison: > > 20 as

Re: [swift-evolution] RFC: didset and willset

> didSet and willSet remain outliers in the general rule of conjoined lowercase > keywords. Is there any support for bringing these outliers into the fold? I would rather like to see them disappear completely — although those "decorators" [is there any established term to describe them?] can be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On May 18, 2016, at 1:52 PM, Brent Royal-Gordon > wrote: > >>> If we're doing this, I wonder if category 1 shouldn't just be >>> `Convertible`. This would preserve our `LiteralConvertible` protocols with >>> the same names (which, consistency issues aside, seem

Re: [swift-evolution] RFC: didset and willset

Not really sure, Like the way the camel case ones look. I’m not sure I understand why keywords are lowercase? To reduce clashes with variables? > On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution > wrote: > > didSet and willSet remain outliers in the

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

> On May 18, 2016, at 12:54 PM, Matthew Johnson wrote: > > >> On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution >> wrote: >> >> Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what >> you'd expect, but does lead

Re: [swift-evolution] Proposal: Finalization in protocol extensions and default implementations

> On May 18, 2016, at 2:21 PM, Sean Heber via swift-evolution > wrote: > > Putting “final” on a default method implementation that is inside of a > protocol extension could maybe make some sense to prevent other > implementations of that method, but final in the

Re: [swift-evolution] Proposal SE-0009 Reconsideration

The code you pasted really ought to print a warning out (allowing variable shadowing without even a warning can lead to annoying bugs), a generation of Swift developers will be trained by relying on the Swift compiler to make their code automagically safe and this is another one of those Not

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

> On May 18, 2016, at 1:33 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I thought about this, but { $0 } is already a fairly compact way to express >> the identity function. > > It is, but I worry a bit about the core team's tendency to say "Oh, just

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

> On May 18, 2016, at 11:40 AM, Joe Groff via swift-evolution > wrote: > >> >> On May 17, 2016, at 8:56 PM, T.J. Usiyan via swift-evolution >> > wrote: >> >> Could we reconsider rejecting the uppercase

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> * What is your evaluation of the proposal? Mostly an enthusiastic +1. This really cleans up one aspect of Swift that seemed un-Swifty. Like others, I would prefer to see the trampoline automatically generated. This is not just a boilerplate issue. Consider the following from the

Re: [swift-evolution] Proposal SE-0009 Reconsideration

See my example with the tableView and the UITableViewDelegate on UITableViewController. `if let x = x` isn't the usual case. The usual case is that you have e.g. tableView instance on the class and a method that takes a tableView parameter. Then you change the method signature not to include

Re: [swift-evolution] Proposal SE-0009 Reconsideration

I always thought that requiring self everywhere was a red herring, and that what was really needed was clearer use of shadowing. But “if let x = x” is a case of the developer asking for shadowing. So either: - shadowing only causes warnings in some places and is allowed in others (and has a way

  1   2   >