Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

If a lot of people (core team included) agree that the current design is less than ideal...why lock in something so important that can never be changed going forward? Why not get it right and force something source breaking that would improve the language for everyone going forward? The

Re: [swift-evolution] [Pitch] Typed throws

I really like this. Seems much more elegant and simple this way > On Feb 17, 2017, at 4:45 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution >> wrote: >> >> I suggest we

Re: [swift-evolution] Move placement of 'throws' statement

I agree this looks better when something is being returned. What would it look like if the function returns nothing but can throw an error? Brandon > On Jan 9, 2017, at 4:10 AM, Tyler Cloutier via swift-evolution > wrote: > > >> On Dec 26, 2016, at 2:55 PM, Dave

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> This keeps leading me back to having submodules or creating modules on > demand. I think that would open up this system to great complexity. I meant "flexibility"...not complexity. Freudian slip?  Brandon ___ swift-evolution mailing list

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Is anyone starting to think the current access control model will become more burdensome over time? People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language.

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Breaking changes, at this point, have a high bar for acceptance. I am failing to see how the downsides presented here are enough to warrant a change. Also: > Developers who follow this rule may accidentally insert newValue or oldValue > in the wrong observer. It is not that uncommon One

Re: [swift-evolution] Some clarity lost from the great renaming

Sorry! I was unsure if this would be a breaking change so thought I would seek feedback. It sounds like I'm not the only one bothered by this so I will file a radar Brandon Sent from my iPad > On Oct 18, 2016, at 9:43 PM, Dave Abrahams via swift-evolution >

[swift-evolution] Some clarity lost from the great renaming

I meant to bring this up a bit ago but just came across it again. I find this to not read properly: button.setTitle("Test", for: .normal) //for normal what? The for argument is really only clear in meaning when you are typing it out and see that it is a UIControlState type. While reading it

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Where should the lack of {public} be reported then? This seems like it falls under jira and not radar because it's in swift open source but I'm not 100 percent Brandon Sent from my iPad > On Sep 4, 2016, at 11:48 PM, Douglas Gregor wrote: > > > > Sent from my iPhone >

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Thank you! I was looking for this last night and failed. Why do you think {public} isn't included? Sent from my iPad > On Sep 3, 2016, at 2:06 PM, Ben Rimmington wrote: > > >> On 3 Sep 2016, at 04:24, Brandon Knope wrote: >> >> I am unsure where to post this…but iOS

[swift-evolution] The great renaming and the state of new Unified Logging in Swift

I am unsure where to post this…but iOS 10 is introducing a new API for activity tracing and logging. The API has been “Swift-ified” a little, but it still is a little awkward to use: os_log("Sender: %{public}@", log: ViewController.ui_log, type: .debug, sender) (This is taken from:

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

Just for the record: I like MemoryLayout. I just had a mental lapse or something. Hopefully it is just me and not others when they first see the API  Brandon > On Aug 8, 2016, at 1:16 PM, Dave Abrahams wrote: > > >> on Mon Aug 08 2016, Anton Zhilin wrote: >> >>

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

I feel so incredibly silly :facepalm: Thank you...it's obvious now Brandon Sent from my iPad > On Aug 7, 2016, at 11:21 PM, Dave Abrahams wrote: > > >> on Sun Aug 07 2016, Brandon Knope wrote: >> >> Yes but: >> >> extension MemoryLayout { >> @_transparent >>

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

n the two in their names and signature, but what is the need for both? It looks duplicated for the most part, so some clarification would be nice. Brandon Sent from my iPad > On Aug 7, 2016, at 10:44 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Sun, Aug 7, 2016 at

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

Can someone quickly explain what this new API does compared to what SE-101 had? I'm trying hard to see what's being added here but my brain isn't working Brandon Sent from my iPad > On Aug 7, 2016, at 10:18 PM, Dave Abrahams via swift-evolution > wrote: > > > on

[swift-evolution] Something lightweight to discuss: improvement to print(_:separator:terminator:) ?

One thing about print that I find odd to look at is when you don't want to use a line break: print(someValue, terminator: "") What if we used an enum for these options, especially for the two most common ones? enum PrintTerminatorTypes { case none case lineBreak //default case

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Using Apple Developer Forums would cause people to leave swift-evolution (a prediction). I don’t think they offer a good enough experience for quick discussions like mailing lists or Discourse do. My question is: would we gain more people than we would lose in moving over to something like

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I wasn't expecting someone else to do it! This would need to be supported by the core team 100% Brandon > On Aug 3, 2016, at 3:42 PM, David Owens II <da...@owensd.io> wrote: > > >> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution >> <swift-evolut

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I still think it is worth doing a test to see how everyone likes it: Move swift-users (users who should see a quick benefit from because it would be more familiar) to discourse and see how that plays out. Let people test out all of the features and performance before moving the most popular

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

There is no way Swift 3 doesn't ship with iOS 10 in September. I think he meant point releases after 3.0 (3.*) will be in 2017 (3 vs 3.* vs 4 was trying to convey this I believe). Swift 3 has to ship with iOS 10 because lots of us are building and updating to iOS 10 and using swift 3. Apple

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Even if we just moved swift-user to a forum as a test, I think it would be greatly revealing and helpful. It would benefit the most overnight. It may be difficult to convince people who have used mailing lists for many years to suddenly move away to something "new". A slow migration on the

Re: [swift-evolution] [Swift4] Priorities and Sugar

Thanks for this! This looks great! Brandon > On Jul 29, 2016, at 9:14 PM, Daniel Duan <dan...@duan.org> wrote: > > >> On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Where ca

Re: [swift-evolution] [Swift4] Priorities and Sugar

Chris, has the core team discussed opening up a forum for discussing proposal implementations. Some of us aren't as skilled as the core team or other contributors but would like to learn. A forum is a much easier place for us to post for code help and to help others with their questions. I

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

This too. I think some better documentation for all of us could pay great dividends. Or a primer of some sort. A weekly series diving into the common parts of LLVM? Brandon > On Jul 29, 2016, at 12:30 PM, Karl <razie...@gmail.com> wrote: > > >> On 29 Jul 2016, at 18:

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

I think this just shows how familiar many of us are with this process. It’s fun and challenging coming up with the great ideas…but someone has to implement it. It may not be fun…and it may be very time consuming. I think a lot of us just expected the core team to implement these all…but they

Re: [swift-evolution] Swift 3.1 vs Swift 4

Wait until August 1st when more will be revealed about post Swift 3 Sent from my iPad > On Jul 26, 2016, at 2:52 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Chris (and Core Team) > > > never,never do > > >for Int i = 0; i < what? ;i++ >

Re: [swift-evolution] Swift 3.1 vs Swift 4

This might need to go through the evolution process: Keg of beer or whiskey?!! B > On Jul 25, 2016, at 5:33 PM, Chris Lattner wrote: > > >> On Jul 25, 2016, at 12:41 PM, Charlie Monroe >> wrote: >> >> I kinda wish that there was a pool where

Re: [swift-evolution] Swift 3.1 vs Swift 4

Thanks Chris! I wish you and the team the best week :) Brandon > On Jul 25, 2016, at 2:34 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Jul 25, 2016, at 10:02 AM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >>

Re: [swift-evolution] Swift 3.1 vs Swift 4

+1 for clarification Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes and anything that has been approved and has not made it into 3.0? Brandon > On Jul 25, 2016, at 12:55 PM, Erica Sadun via swift-evolution > wrote: > > Will there be a

Re: [swift-evolution] [Draft] Swift implementation Regex added

There has been talk on this list of adding a fully featured RegEx feature. It has been pushed back to a later release as the window for Swift 3 is closing Brandon > On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution > wrote: > > My first proposal so

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

I guess my question comes down to this: Is this a change for consistency OR is there actually a tangible benefit? If it's a protocol: you know some methods are being implemented. If it's a base class: it's possible that some methods are overridden Between knowing these two things, what does the

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,

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] [Proposal][Discussion] Qualified Imports

I meant is there any reason for requiring parentheses > On Jul 20, 2016, at 4:53 PM, Robert Widmann wrote: > > Renaming is out of scope for this proposal, that’s why. > >> On Jul 20, 2016, at 1:26 PM, Brandon Knope wrote: >> >> I prefer this 100x more >>

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I prefer this 100x more Is there any reason why this wouldn't work? Brandon > On Jul 20, 2016, at 4:13 PM, Xiaodi Wu wrote: > > Yeah, I'd be happy to lose the parentheses as well. > > In the last thread, my take on simplifying the proposed syntax was: > > ``` > import

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

> On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution > wrote: > > As Joe and others mentioned in the previous thread, this syntax could be > greatly simplified in ways that resemble analogous facilities in other > languages. In particular I think it's

Re: [swift-evolution] Discussion: Last chance to rename .self and .Self?

g/pipermail/swift-evolution/Week-of-Mon–20160711/024439.html > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. Juli 2016 um 21:25:50, Brandon Knope via swift-evolution > (swift-evolution@swift.org) schrieb: > >> July 27th is last day for break

[swift-evolution] Discussion: Last chance to rename .self and .Self?

July 27th is last day for breaking source changes for Swift 3...so I thought I would bring this up one final time. Opinions: - .self and .Self do not adequately convey what they do without some mental gymnastics - self has somewhat two meanings (accessing a property on the type and getting

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

But in general, if I use enums, I have more cases than I normally would have of if-else statements. I try not to have many if-else chains but I generally have 2+ cases which would result in more braces than my typical if-else > On Jul 7, 2016, at 4:41 PM, G B via swift-evolution >

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

When each case only takes up one line, it may look nice and concise. But what happens in the common case when your case takes up more lines and you indent your braces? > switch x { > case 0 { print(0) } > case 1 { print(1) } > case 2 { print(2) } > default { print("other”) } > } switch x {

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

A few questions: 1. What is universal lookup? How is this different than the compiler having to search a crowded namespace? I'm really trying to understand how this is making it easier for the type checker. 2. If operators are a special case, why not replace static/class func with an

Re: [swift-evolution] [Pitch] Remove type inference for associated types

:P >} > > There will always be bugs, of course. Maybe this isn’t a significant concern? > > l8r > Sean > > > >> On Jun 29, 2016, at 8:55 AM, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> What's the

Re: [swift-evolution] [Pitch] Remove type inference for associated types

What's the rationale for having associatedtype in protocols and typealias in the conforming types? This has actually been a point of confusion for me as it seems inconsistent Brandon Sent from my iPad > On Jun 29, 2016, at 1:33 AM, Douglas Gregor via swift-evolution >

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

Just wanting to point out that option 2 could look vastly different! Neither looks "pretty", but the first one sure looks good  Brandon > On Jun 28, 2016, at 8:08 PM, Dave Abrahams wrote: > > >> on Tue Jun 28 2016, Brandon Knope wrote: >> >> Isn't dynamicType

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

Isn't dynamicType possibly changing soon to a method? This could look much different Brandon > On Jun 28, 2016, at 4:53 PM, Erica Sadun via swift-evolution > wrote: > > On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution >

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

I'm just concerned that precedencegroup might be confusing at first look. But like you said, it's not going to be a widely written feature (but it's will be widely used!). Also, is taking a keyword at the top level really that bad? Precedence could still be used inside classes and methods

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] [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] 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] 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

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

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

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] 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

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

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] [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] [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] [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] [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

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] [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] [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)

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] [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] [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] [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] [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

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] [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] [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

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

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] [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

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] [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

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] 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] 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] 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] 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

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

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] 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] 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] 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] [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] 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] 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

[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] [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] [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

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

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

  1   2   >