Re: [swift-evolution] Changing postfix "self" to something clearer like "type"

"let x: SomeType".) > > I think coming up with a clearer name is possible here, but there's plenty to > consider. Still, certainly a reasonable thing to bring up. > > Best, > Jordan > >> On Dec 15, 2015, at 8:42 , Brandon Knope via swift-ev

[swift-evolution] Discussion: Why is "nil" not "none"

Quick thought: If optional has a .none case, wouldn't it be more consistent to rename nil to none? Also, would nil make it into Swift if not for other languages? It also might make it somewhat clearer: var someInt: Int? = none //looks less like a pointer and more like a value of nothing 1.

Re: [swift-evolution] Discussion: Why is "nil" not "none"

> On Jun 8, 2016, at 11:54 AM, Антон Жилин via swift-evolution > wrote: > > The difference between nil and .none is that the former is more "generic" > than the latter. > > NilLiteralConvertible protocol expresses types that can contain "null" as > legal

Re: [swift-evolution] Discussion: Why is "nil" not "none"

ing none. you can do: >>> >>>let a : Int? = .none >>>let b : Int? = .some(5) >>> >>>Using the simpler >>> >>>let a : Int? = nil >>>let b : Int? = 5 >>> >>>is just sugar. >>>

Re: [swift-evolution] Discussion: Why is "nil" not "none"

I know I know. I should have framed this as removing NilLiteralConvertible from Optional and supplying it with a new keyword. I don’t find nil to adequately represent what it is doing with optionals. It *looks* like it is setting a object to nil when this really isn’t the case. The optional

Re: [swift-evolution] Remove nil and NilLiteralConvertible

Is it really an implementation detail? It is very leaky if it is one because it is highly exposed to everyone. Regardless of whether or not it is an implementation detail, nil does not adequately describe the “none” case it is trying to represent in my opinion B > On Jun 8, 2016, at 4:56 PM,

Re: [swift-evolution] Remove nil and NilLiteralConvertible

.none or a more appropriate keyword like “none” (imo) Brandon > On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution > wrote: > > It's been pointed out before that Optional being an enum type is treated like > an implementation detail. Currently, it is

Re: [swift-evolution] Remove nil and NilLiteralConvertible

> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution > wrote: > > > > > So are you proposing to disallow the following: > > let myStrings = ["s1": "hello, world", "s2": "something else"] > myStrings["s2"] = nil > > Replacing it with the following:

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

dy >>> seen, or challenge their ideas in ways they might not have anticipated. But >>> nowhere does it say (and I will immediately drop any further interest in >>> Swift if someone tells me it should be that way) that their role is to >>> dutifully record what

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

ould be that way) that their role is to dutifully > record what the plebe wants and deliver it as best as they can. Taken > together, some of the most individually popular suggestions would undoubtedly > lead to some sort of franken-swift that not even the people pushing these > ideas for

Re: [swift-evolution] Remove nil and NilLiteralConvertible

gn nil to >>>> an optional >>>> >>>> B >>>> >>>> Why would nil be chosen to represent the none case in the absence of other >>>> languages? >>>> >>>> >>>>> On Jun 8, 2016, at 4:55 PM,

Re: [swift-evolution] Philosophy of Swift

My favorite is that Swift is an opinionated language :P "We intentionally want Swift to have a common “center of gravity” and be an “opinionated” language, rather than fall to the “design by committee” approach that leads to a watered-down design” This was from Chris Lattner Reference: Re:

Re: [swift-evolution] Discussion: Why is "nil" not "none"

. > > It’s true that we might not have picked nil if it hadn’t been for > Objective-C, but that doesn’t make it an invalid choice. There are lots of > things in Swift we might have done differently if it weren’t for Objective-C > and Cocoa. > > Jordan > > >> On

Re: [swift-evolution] Discussion: Why is "nil" not "none"

6, at 8:10 PM, Saagar Jha <saagarjh...@gmail.com> wrote: >>> >>> Well, some is the opposite of none in that if I don’t have some, I have >>> none. nil is just a carry-over from Objective-C. >>> >>>> On Tue, Jun 7, 2016 at 5:07 PM Bran

Re: [swift-evolution] Discussion: Why is "nil" not "none"

just a carry-over from Objective-C. > >> On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> I guess for me it comes down to this: >> >> Why were some and none chosen for as the cases for Optional? &g

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Sent from my iPad > On Jun 8, 2016, at 5:59 AM, Jeremy Pereira <jeremy.j.pere...@googlemail.com> > wrote: > > >> On 8 Jun 2016, at 03:10, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> On the other hand...

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Well now you have me intrigued. I must read more about Linq now Brandon Sent from my iPad > On Jun 12, 2016, at 6:02 AM, L Mihalkovic via swift-evolution > wrote: > > >> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu wrote: >> >> >> >> On Sat,

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

ess may not be optimal > for complex multi-faceted problems that are on the horizon, like creating a > metadata system, macros, kernel and driver software (?), … It will sure be interesting what happens after Swift 3! Brandon > > >> On Jun 9, 2016, at 10:16 AM, Brandon Knope via

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Isn’t Swift too young to have any sort of established dialect? Removing everything takes away from an organic process of discovering what the dialect will be. Instead we are shoehorning a dialect in the early stages of swift when a lot hasn’t even been established yet. Maybe the mistake is

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

++ (which I do not enjoy writing in). I hope this makes some sense about my perspective Brandon > On Jun 10, 2016, at 3:52 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, Jun 10, 2016 at 2:38 PM, Brandon Knope via swift-evolution > <swift-evolution@swift.org &l

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Thanks for the laugh! The last week or so is actually stressing me out about the direction where swift is going… I hope it is just a fleeting feeling but that remains to be seen. I am beginning to think my interests and taste are no longer aligning with the communities or core teams.

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On Jun 10, 2016, at 1:47 PM, Roth Michaels via swift-evolution > wrote: > > While I did not get a chance to review all the discussion in time to > respond to the proposal, I am happy with the revised version that was > approved (the semi-colons were a point of

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

nd of possible improvement that would interest me more vs just > keeping it as-is. > > > Given that today’s been a bit of a whirlwind for the where clause I’m not > sure where to fall on this yet. I’m definitely more in favour of this > compared to removing the where clause ent

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant wrote: >> >>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution >>> a écrit : >>> >>>

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

I have just one last thing to say on this topic as it is clear it is going into the language and no accepted proposal has been overturned that I am aware of. I believe with this cycle, the swift evolution process didn't work. And here is why I think this: - This proposal began as a discussion

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Can you include an example? I find it hard to visualize for case? pattern where-clause? in expression code-block Thanks, Brandon > On Jun 9, 2016, at 3:05 PM, Erica Sadun via swift-evolution > wrote: > > Gist:

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Sent from my iPad On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon wrote: >> I believe large syntax changes should have more discussion from more >> developers and not a very small subset of them. The review announcement >> needs to be broader: the swift blog needs to

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > > >> On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPad >> >> On Jun 9, 2016, at

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

:) > > Just my two cents, > Ethan > > [1] Swift is indeed an opinionated language. > > > Sent from my iPhone. > >> On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>

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

Any updates about the status of this review? Thanks, Brandon > On May 17, 2016, at 11:30 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0077: Improved operator declarations" begins now and runs > through May 23. The

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

nual of > style you choose)? > > Jacob > >> On Fri, May 27, 2016 at 7:28 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> As a *user* of the language, I find it a little disconcerting that we would >> make the syntax uglier jus

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

Sent from my iPad > On May 27, 2016, at 8:13 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Second, I have really gotten use to not nee

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Are you really surprised that some people don't want this taken away? The burden should be on those that want it taken out of the language and not those that want it kept. After all something is being removed and it should be a delicate process. Don't be surprised when the defenders say it is

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Sent from my iPad > On Jun 13, 2016, at 9:36 AM, Xiaodi Wu wrote: > >> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope wrote: >> Are you really surprised that some people don't want this taken away? > > Nope, that's to be expected. > >> The burden should

Re: [swift-evolution] Remove nil and NilLiteralConvertible

gt; >> >>> On Jun 8, 2016, at 4:55 PM, Sean Heber <s...@fifthace.com> wrote: >>> >>> If you add a new keyword called “none” without the period, but keep >>> allowing “.none” to work because Optional is really an enum… then I don’t >>> really

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

I am deeply saddened that a little part of character is lost in swift with the removal of where (imo). But I can be happy that ; is not being used I guess. My question: what is/was the rationale for adding where to swift 2? We seem to just be removing it everywhere now (or at least the

Re: [swift-evolution] Remove nil and NilLiteralConvertible

I think you know I am very +1 on this :) Brandon > On Jun 8, 2016, at 4:41 PM, Антон Жилин via swift-evolution > wrote: > > (No joking) > Points: > > 1. When nil was added to the language, we could not infer enumeration type: > if x != Optional.none { ... } > >

Re: [swift-evolution] Remove nil and NilLiteralConvertible

same thing! > > l8r > Sean > > >> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> .none or a more appropriate keyword like “none” (imo) >> >> Brandon >> >>> On Jun 8, 20

Re: [swift-evolution] Remove nil and NilLiteralConvertible

Isn’t the only thing keeping nil relevant is the NilLiteralConvertible protocol? Brandon > On Jun 8, 2016, at 5:08 PM, John McCall via swift-evolution > wrote: > >> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution >> wrote: >>

Re: [swift-evolution] Remove nil and NilLiteralConvertible

whereas in most languages it is not safe to dereference a nil pointer - It is not consistent with the Optional enum naming - It is not as descriptive or expressive Brandon > On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution > <swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I'm not sure how feasible this is...but why not remove the conditional case to remove the ambiguity? Conditional case seems somewhat esoteric compared to the current behavior that many people are used to. (I.e. How many know of and use a conditional case?) Is it worth de-beautifying the syntax

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

ior is inconsistent. >> >> -Thorsten >> >> >>> Am 28.05.2016 um 22:18 schrieb Brandon Knope via swift-evolution >>> <swift-evolution@swift.org>: >>> >>> Doesn't this contextually make sense though? >>> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except some of us have proposed only allowing unwrapped or newly bound variables in the where clause: if let y = y where y < z should work If let y = y where x < z should be an error because it doesn't need to be in a where clause and doesn't make sense contextually. I understand the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

To be frank, I just find the proposed syntax to be more ugly and less expressive. I just don't find the proposal compelling enough to take away one of the truly "Swifty" syntaxes that I have used and loved. If there are other ways to keep "where" while fixing the ambiguity I would rather

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except "b" is the main focus of the where clause and b was just in the preceding if condition. I feel like we are trying to find ways to break the current where clause even though we've enjoyed it for almost a year now. I had no idea it was problematic and restrictive. I thought it made its

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let y = y && x < z They are, after all, independent from each other. Brandon > On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

The y == y I presume is to get around this requirement by reintroducing a variable in the previous part of the conditional to be able to refer to other variables. x > z isn't allowed, but y == y && x > z would be because it's using y. I'm not convinced anyone would do this when they could

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let x = x where x > 10, y != 5, let z = z where z != x Just as a contrived example? Brandon > On May 31, 2016, at 4:03 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 2:59 PM, Brandon Knope wrote: >> Except "b" is the main focus

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

And why couldn't we propose that it should? Brandon > On May 31, 2016, at 4:14 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope wrote: >> What is wrong with: >> >> if let y = y && x < z >> >> They are, after all, independent from

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Why would that argue for the removal of where if let y = y where y != 5 && x < z I would still prefer: if let y = y where y != 5, x < z, let z = someOptional where z == 10 To me, where still has a place. And that place is saying "hey this is a recently introduced or shadowed variable, so don't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except I disagree. It might seem like a stylistic flourish, but it can be more expressive in informing the reader that the variable after the where clause was recently introduced somewhere in the preceding clause. Without it, you'd have to scan the entire conditional clause and around the

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I am giving a -1 for this proposal. While I am sure it has merit, I am finding it to be a really technical change (meaning it makes the language look more technical at the expense of some of its beauty) First, I do not find this example very compelling: guard x == 0, let y = optional

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I could be pedantic and say that "previousInterestingFoo" now relies on the newly bound "foo" on assignment in the while loop keeping it relevant contextually. Ultimately, my responsibility as a user of the language is not to try to figure out the inner workings of the grammar or the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 29, 2016, at 3:39 PM, Chris Lattner via swift-evolution > wrote: > > I can definitely respect the position that “where” feels more readable than a > semicolon, it certainly provides a more “fluent” style. > > That said, the existing Swift 2 syntax was

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

hat implies it is not a key > that is used very often, which further implies it *should* be a little out of > the way. > > *The* escape character for strings is “\”. Please let’s not introduce a > second one. > > >> On 22 Jun 2016, at 00:08, Brandon Knope via swift-

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

This is one of those things that *could* have a guideline, but it still wouldn't stop people from doing it their own way > ___ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

the parentheses characters than $ is >>>>> and (if you assume we are going to replace parentheses with braces as was >>>>> suggested upthread) right next to the brace keys. >>>>> >>>>> Anyway, your heat map evidence actually negates the arg

Re: [swift-evolution] [SE-0088] Dispatch API names

I'm not convinced that perform is clearer than async. performAndWait *is* clearer than sync but only in context: you wouldn't know perform was async until you read it or noticed the difference with performAndWait. Nothing about *perform* on its own conveys that it's asynchronous. Brandon

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

s can be >> pretty… big. >> >> Also, $ is not the only option. There are still far easier keys to type than >> \. >> >> Brandon >> >>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >&g

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

something used by everyone. The usability cost is there and it is >>>> real. Just because “well it is easy for me to type” does not mean that it >>>> is ideal. It also doesn’t mean that the current choice is the wrong choice >>>> either. But it still is importa

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

Actually… we can go pretty scientific on this sort of thing and heat map keyboard usage to get a better picture of how “usable” this is. I pasted a file that contains seven \’s in it and heat mapped it at https://www.patrick-wied.at/projects/heatmap-keyboard/ Even *with* several \’s throughout

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

to that bigness can be pretty… big. Also, $ is not the only option. There are still far easier keys to type than \. Brandon > On Jun 21, 2016, at 7:15 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution > <swif

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

Unfortunately I know nothing about international keyboards. But surely someone could heat map their international keyboards? I don't want to take this to ridiculous levels, but I hope I am making somewhat of a point here. Maybe not =/ Brandon Sent from my iPad On Jun 21, 2016, at 7:38 PM,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

I have to say, this might be the most swifty of the swift proposals. There's something about it that's elegant and beautiful, so big +1 from me. I do think Never makes more sense, but I understand the clarity that NoReturn brings. For a feature that most probably won't even use, maybe we

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

I agree big time. It is pretty awkward to type and I completely understand the angst when having to type it! $() seems like the better option, though maybe not as nice looking as \() (maybe it is on second thought?) it is much easier to type! Brandon > On Jun 21, 2016, at 5:22 PM, Saagar

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Isn't this more caused by confusion about how infinite sequences work? The prefix one is no longer an infinite sequence. The second one still is. The second one will always infinite loop unless you break Brandon Sent from my iPad > On Jun 22, 2016, at 5:28 PM, Erica Sadun via swift-evolution

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

> On Jun 24, 2016, at 11:06 AM, Sean Heber via swift-evolution > wrote: > And these 2 made good use, IMO, of “if-where” but I think that’s no longer in > Swift 3? :/ > > > if let there = debugClickedSurfaceAt, here = mouseSurface where > Global.debugPathTest { >

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

Maybe something like this? let calendar = Calendar.current() for date in dates where calendar.isDateInToday(date) { //process date only in today } VS. for date in dates { guard calendar.isDateInToday(date) else { continue } } The where keeps the body of the for loop uncluttered

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I am really not in favor of the parametrized access keywords. To me, private(module) and private(file) seem redundant. Module already implies it is restricted to the module, and file already implies it is restricted to the file so the private keyword just seems unnecessary in my opinion.

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

Because I am a mailing list noob, my email wasn't CC'd to all. So here we go again: Big +1 from me. I expected not to like this syntax but I believe it makes it far clearer. It always felt backwards to me to have to come up with all the constraints before the function signature. Maybe this

Re: [swift-evolution] Proposal: disallow nil in favor of .None

Just to be a little pedantic (with a point though): This will actually become .none in swift 3 which actually makes me support this idea even more. nil -> .None looks goofy to me nil -> .none looks just right But this is a bold change and is something people are use to from other languages,

Re: [swift-evolution] Proposal: disallow nil in favor of .None

What about adding a none keyword as a shortcut for .none? Might be a little more consistent with optionals than nil which brings to mind pointers for most people Sent from my iPad > On Apr 10, 2016, at 5:13 PM, Radosław Pietruszewski via swift-evolution > wrote: >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > >public >moduleprivate >fileprivate >private > > The advantages, as I see them are: > 1) We keep public and private meaning

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

You perfectly articulated what I've been trying to say and I agree 100% with your concerns. While we are in a minority, I think it's important to consider how the use of private in three keywords could become confusing to people learning the language and even just in a slight mental lapse

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 24, 2016, at 6:10 PM, Brent Royal-Gordon via swift-evolution wrote: > Honestly, though, I'm not sure why people are working so hard to cram > `private` in there. Does `moduleprivate` or `private(module)` really convey > more information than `module`?

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I'd be okay with this, but I do think having a private and fileprivate will confuse people considering they both have private in their names Brandon Sent from my iPad > On Mar 31, 2016, at 12:22 AM, Chris Lattner via swift-evolution > wrote: > >> On Mar 23, 2016,

Re: [swift-evolution] Static Dispatch Pitfalls

> On May 20, 2016, at 12:46 PM, David Waite via swift-evolution > wrote: > > >> On May 20, 2016, at 10:17 AM, Austin Zheng via swift-evolution >> wrote: >> >> I almost want to propose forbidding methods in protocol extensions unless

Re: [swift-evolution] Static Dispatch Pitfalls

Because I think the dynamic case is what most people expect and should be the default. The unexpected behavior should be the opt in behavior as you know what you are doing at this point. At least this is my reasoning Brandon > On May 20, 2016, at 1:39 PM, Krystof Vasa via swift-evolution >

Re: [swift-evolution] Static Dispatch Pitfalls

I was kind of alluding to this when I said it should be opt in...or at least I thought I mentioned it . What keyword name could clearly convey this meaning? Brandon > On May 20, 2016, at 1:35 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 20,

Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

are used to seeing > abbreviations in capital letters - from this point, it's better readable. > >> On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Do you have a particular reason? I don't think becaus

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

Looking real good (especially the alternative section :P)! What's the rationale for using upper and lower? My objection to this is how it can be read: "precedence addition associativity left upper XXX lower XXX" I think upper and lower kind of break the flow of how it is read. This seems

Re: [swift-evolution] [Discussion] Namespaces

This would be out of scope for Swift 3 right? Or is this relatively "easy" to implement? Brandon Sent from my iPad > On May 20, 2016, at 11:27 AM, Tony Allevato via swift-evolution > wrote: > > Another use case to consider: code generation. There, namespaces can

Re: [swift-evolution] [Discussion] Namespaces

I'm pretty sure he meant "cross dependencies" Brandon Sent from my iPad > On May 20, 2016, at 12:06 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution >> wrote: >>

Re: [swift-evolution] Static Dispatch Pitfalls

>From the compilers/runtimes perspective why couldn't the declaration >automatically be included in the main protocol definition as if it was defined >there? Brandon > On May 20, 2016, at 12:21 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 20,

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

What is your evaluation of the proposal? A big +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes. This makes it much more natural to read methods and functions with generics. This also makes it more predictable to find where the method signature is

Re: [swift-evolution] [Idea] if let value!

It’s not just about being concise, but reducing repeated code: It would be syntactic sugar for this: if case .Some(let optional) = optional { } But yes, unwrap makes much more sense. At the end of the day, I am not too bothered by if let syntax, but if we could clear up some of the

Re: [swift-evolution] [Idea] if let value!

I always thought a new keyword made more sense here: if let rebind someValue { //use shadowed unwrapped value in here } if let bind someValue { //use shadowed unwrapped value in here } if let unwrapped someValue { } Something along those lines? Brandon > On May 17, 2016,

[swift-evolution] Idea: Named extensions

I like to separate methods into their own logical extensions so similar methods are grouped together. I do this mostly with Cocoa Touch where I like all view life cycle methods to be in the same extension: extension ViewController { override func viewDidLoad() { } override func

Re: [swift-evolution] Idea: Named extensions

1:33 PM, Michael Peternell <michael.petern...@gmx.at> > wrote: > > Why not just use a (documentation) comment? > > /// The Lifecycle extension: > extension ViewController { > ... > > -Michael > >> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-e

Re: [swift-evolution] Idea: Named extensions

t; > >> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Why not just use a (documentation) comment? >> >> /// The Lifecycle extension: >> extension ViewController { >> ... >&

Re: [swift-evolution] Idea: Named extensions

3, but may revive in the > future). > > >> ... >> >> -Michael >> >>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution >>> <swift-evolution@swift.org>: >>> >>> I like to separate methods into their own l

Re: [swift-evolution] Idea: Named extensions

>>> >>> /// - Keyword: Lifecycle extension >>> >>> -- Erica >>> >>> >>>> On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] Idea: Named extensions

yan <griotsp...@gmail.com> wrote: > > I have wanted this feature and floated it a while back. I hope we can get > some traction this time but I doubt it will happen soon since additive > features are tabled for a time. > > On Mon, May 16, 2016 at 3:47 PM, Brandon Knope vi

Re: [swift-evolution] Idea: Named extensions

; > On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I think requiring them to be in comments is what’s going to prevent their > adoption. > > My fundamental stance is

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

I like this proposal but I believe the syntax could be better. I think this would read more naturally: precedence Multiplicative { above Additive left } I would suggest using above, below, equalto, for the precedence values. I think it reads more naturally and, like others have said, I find

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I'm just concerned about the obviousness of it. If what we are doing is just grabbing the type, why couldn't it be: someClass.Type (like in the generic system) I'm open to Self, but I just want to make sure we exhaust all avenues that are more obvious at a glance: .Self.Type .ThisType

Re: [swift-evolution] Feature proposal: Range operator with step

What about "strideby" Brandon > On Apr 14, 2016, at 8:57 PM, Hans Huck via swift-evolution > wrote: > > Erica Sadun via swift-evolution writes: >> >> >>> On Apr 14, 2016, at 1:42 PM, Hans Huck via swift-evolution > swift.org> wrote: >>>

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

-1 from me. To me this is not *obvious* as to what "Self" it means. And it seems possible to run into this: self.someClass.Self Just looks confusing to me. What's wrong with using "Type" or something more obvious? Sent from my iPad > On Apr 14, 2016, at 10:28 AM, Vladimir.S via

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

Honest question: what is actually confusing about the current behavior? I.E. What is important about knowing whether "DataSource" is a class or a protocol? I thought the blurred distinction was intentional? Brandon > On Jul 22, 2016, at 9:47 AM, Charlie Monroe via swift-evolution >

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

I understand. But why would you need to know if it's a class or a protocol to use the type? What understanding comes from knowing this information? I am honestly trying to understand the problem here and it feels like I'm overlooking something. Brandon > On Jul 22, 2016, at 10:12 AM,

  1   2   >