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

> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution > wrote: > > I once suggested the following ternary like switch: > > let x = color ? > case .Red: 0xFF > case .Green: 0x00FF00 > case .Blue: 0xFF > default:

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

>> And maybe allow a special case for boolean where you can leave off the “case >> true:” part: >> >> let x = something ? thing() else: otherThing() >> >> And then you could more or less replace ternary with this new construct that >> can do even more while looking very similar and still being

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

I don’t understand this argument about googleability of “type” being a problem. All of the errors and documentation talk about “associated type” and having the word “type” literally visually associated with the word “protocol” right there in the code I’m looking at makes perfect sense to me.

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

For me there are two sources to the feeling of noise with simple single-statement closures and using $0, etc. - The first are the braces that seem redundant when there’s only a single statement, and the second is the presence of $0. I played around a bit, and this is probably just a personal

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

I may just not be understanding what this is trying to solve, but the following would work too, wouldn’t it? enum NetworkException { case NoInternetError, SecurityError } enum ParseException { case FailedResponse(statusCode: Int) case EmptyResponse case MissingField(fieldName: String) }

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

This worked for me: enum NetworkException: ErrorType { case NoInternetError, SecurityError } enum ParseException: ErrorType { case FailedResponse(statusCode: Int) case EmptyResponse case MissingField(fieldName: String) } enum ChangePictureError: ErrorType { case

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

This might be silly, but what if there were a struct with all of the relevant fields (not sure what the best name would be): struct MemoryLayout { let size: Int let alignment: Int let stride: Int // etc } Then you’d only maybe need two functions: memoryLayout(of:) and

Re: [swift-evolution] Remove nil and NilLiteralConvertible

If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t. If enum cases could be referred to without the leading “.” then

Re: [swift-evolution] Remove nil and NilLiteralConvertible

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 see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing! l8r Sean > On Jun 8, 2016, at 3:52

Re: [swift-evolution] Remove nil and NilLiteralConvertible

on details-now you have to explain that Optionals are >> actually enums internally. Using nil doesn’t lead to this kind of scenario, >> and they already (mostly) know what it means from other languages. >> >> On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution

Re: [swift-evolution] Add a while clause to for loops

There might be value in entertaining the idea of unifying constructs such that they all allow arbitrary combinations of for/while/where/etc. Such as: while !stopped for unit in workToDo where unit.passesTest(condition) { unit.process() } Which would mean something different than: for unit in

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

I share the concern of this being a weakness of the process, but I don’t know what the alternative is (besides shutting it down and sealing the sausage-making back inside of Apple where we can’t see it :P) I do think, though, that perhaps in the future maybe there should be a moratorium on

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

> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift > Repos" folder and did the same search. Among the 15 repos in that folder, a > joint search returned about 650 hits on for-in (again with some false > positives) and not a single for-in-while use. Weird. My own Swift

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

> Here, though emotion is hardly a worthy barometer, I had quite a visceral > reaction to the example given at one point: > > ``` > for number in fibonacci where number % 2 == 0 while number < 4_000_000 {...} > ``` > > This, IMO, is long enough to cause a heart attack. To me, that looks

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

There was also my suggestion for a function such as memoryLayout(of:) that returned an instance of a simple MemoryLayout struct which I believe is a bit different than the MemoryLayout generics approach. I’m not sure if that was expressly shot down or ruled out or not, though. l8r Sean > On

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

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution >> wrote: >> >> I am 100% with Charlie on this. Expressiveness has to do with the >>

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

I’m just (probably obtusely) suggesting that there are different levels and styles of expression and that the existence of one does not render other styles invalid. In relation to the “where” debate, the fact that you can express everything with “guard” or “if” as you can with “where” is not,

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

> On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe > wrote: > if-continue. But I gladly took upon for-in-where as soon as I found out about > it since it's more

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

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution > wrote: > > >>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon >>> wrote: >>> >>> Upon accepting SE-0099, the core team is removing `where` clauses from >>> condition

Re: [swift-evolution] Add a while clause to for loops

They would differ in, what at least to me, seems pretty logical ways: >> while !stopped for unit in workToDo where unit.passesTest(condition) { >> unit.process() } Would be: while !stopped { for unit in workToDo where unit.passesTest(condition) { unit.process() } } >> for unit in

Re: [swift-evolution] [swift-evolution-announce] [Rejected] SE-0097: Normalizing naming for "negative" attributes

In terms of naming, I almost feel like “None” would be a better name for it as then it reads somewhat as the opposite of “Any” and that has a nice symmetry to me. l8r Sean > On Jun 2, 2016, at 4:04 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> 1) For

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 l8r Sean > On Jun 2, 2016, at 1:46 PM, Austin Zheng via swift-evolution > wrote: > > +1. > > The primary advantage is that it aligns the language semantics with how most > programmers expect this common C-language-family idiom to behave and removes > a

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

> The review of "SE-0102: Remove @noreturn attribute and introduce an empty > NoReturn type" begins now and runs through June 27. The proposal is available > here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md > > * What is your

Re: [swift-evolution] the "guard" keyword, again

> In the Commonly Rejected Changes page and in this swift-evolution email to > which it refers, I read that first there was “unless", then “require” then > finally “guard ... else”. > > I couldn’t find the earlier discussion in which “unless” was replaced for a > while by “require”, so I am

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

The situation is very different on an iPad. I don't think this argument is a good enough reason either. It will differ based on locale, accessibility technology, device, personal key shortcuts, etc. l8r Sean Sent from my iPhone > On Jun 21, 2016, at 6:52 PM, Brandon Knope via

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

> The review of "SE-0103: Make non-escaping closures the default" begins now > and runs through June 27. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md > * What is your evaluation of the proposal?

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

> The review of "SE-0095: Replace `protocol` syntax with `Any`" > begins now and runs through June 27. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md > > * What is your evaluation of the

Re: [swift-evolution] Stdlib closure argument labels and parameter names

How about: let results = possibilities.where(matching: closure) :) l8r Sean Sent from my iPad > On Jun 22, 2016, at 8:00 PM, Xiaodi Wu via swift-evolution > wrote: > > filter(extractingWhere:) >> On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution

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

> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now > and runs through June 29. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md > * What is your evaluation of the

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

My only feedback at the moment is that “Syntax” seems like a weird name. This is all about literals, right? So why not use: Literal.Integer Literal.Float Literal.String etc. l8r Sean > On Jun 23, 2016, at 10:31 AM, Matthew Johnson via swift-evolution > wrote: >

Re: [swift-evolution] Prohibit invisible characters in identifier names

I’m no unicode expert, but this sounds like the way to go to me. l8r Sean > On Jun 23, 2016, at 11:17 AM, João Pinheiro via swift-evolution > wrote: > > >> On 21 Jun 2016, at 20:15, Xiaodi Wu via swift-evolution >> wrote: >> >> On

Re: [swift-evolution] Prohibit invisible characters in identifier names

+1 l8r Sean > On Jun 20, 2016, at 12:51 PM, João Pinheiro via swift-evolution > wrote: > > Recently there has been a screenshot going around Twitter about C++ allowing > zero-width spaces in variable names. Swift also suffers from this problem > which can be

Re: [swift-evolution] Compiler Warning on Unextended Classes

I would think this would not apply to public classes. There has also been discussion in the past about making final the default - I don’t remember if that ever resolved into some kind of consensus or not, though. l8r Sean > On Jun 16, 2016, at 11:23 AM, Saagar Jha via swift-evolution >

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

This is certainly surprisingly behavior to me! +1 l8r Sean > On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution > wrote: > > Consistent formal type for 'self' in class methods > > • Proposal: SE- > • Author: Slava Pestov > •

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

I’ll share some of mine from a single game project. Note this hasn’t been converted to Swift 3 and this is not all of them - just a varied sampling: for location in random.sample(map, density: 0.007) where map.allowsGrassAt(location) && !map.hasGrassAt(location) { } for location in

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

let data = text.data(usingEncoding: > NSASCIIEncoding) { > /// Do something with data or text > } > > >> On Jun 24, 2016, at 5:06 PM, Sean Heber via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I’ll share some of mine from a sin

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

> On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 24, 2016 at 6:37 AM, William Shipley wrote: > On Jun 23, 2016, at 11:04 PM, Xiaodi Wu wrote: >> >> Not a practitioner of 80-character line

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Just tossing my vote in the hat for renaming .filter() to something like .select() since that better matches what it does, IMO. “Filter” is almost like the opposite word from what it should be since the closure returning true is what decides what is included in the results, not what is filtered

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

Yeah, I like that they have a common prefix, but I sort of don’t like how that all looks, either. What if they were grouped first by the fact that they are delegates? func dataSource(tableview: UITableView, numberOfRowsInSection section: Int) -> Int func delegate(tableview: UITableView,

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

e another name, but also allow > for things like alternate spellings. > > > Jeff Kelley > > slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org > >> On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution >> <swift-evolution@swift.org> wrote:

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

Here’s a perhaps unlikely “what if” idea that is tangentially related to the problem that FP and mathematical names are sometimes weird in Swift and often don’t have a place to “live” that makes sense. Let’s say we add an ability to declare a function on a struct/protocol/class/enum as a

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

And along a similar line of thinking, what about a @termOfArt() attribute that similarly redefines or provides additional names for things. This way the name in the standard library/etc would be the “Swift” version of the name - but there’d be a way to use it and find it even if you’re familiar

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md > > • What is your evaluation of

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

Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know. l8r Sean > On Mar 14, 2016, at 9:38 PM, Sean Heber wrote: > > I, too, prefer it to be more like this: > > public // unchanged >

Re: [swift-evolution] Making `.self` After `Type` Optional

Bumping this - did anything ever become of this? It seemed like there was general agreement to do something about the “.self” requirement when referencing types. I would personally like to see it go away. l8r Sean > On Mar 9, 2016, at 1:23 PM, Tanner Nelson via swift-evolution >

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

I, too, prefer it to be more like this: public // unchanged module // currently internal internal // currently private private // new hotness l8r Sean > On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution > wrote: > > +1 > > I like this a lot.

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

How would you handle translating the existing private(set) and the like with this syntax? It seems like it could get confusing and perhaps end up in a situation where you have something like private(file, set) but then you have to constantly remember which order the parameters are in. l8r Sean

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

I use this feature from time to time, but not usually intentionally. I appreciate that it doesn't force me to rearrange a bunch of parameters at call sites just because I happen to change the order of them in the function declaration, though. l8r Sean Sent from my iPhone > On Mar 30, 2016,

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

Yes, absolutely this - I'd likely be fine with the order of them being strict, but being able to omit ones that I want to be defaulted is a must. l8r Sean Sent from my iPhone > On Mar 30, 2016, at 12:06 PM, William Dillon via swift-evolution > wrote: > > As long

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

This almost seems like it could work so that it didn't even need the bracketed parts to be able to figure out the types: func anyCommonElements(lhs: T, _ rhs: U) -> Bool where T : SequenceType, U : SequenceType, T.Generator.Element: Equatable, T.Generator.Element ==

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

*grabs paintbrush* Something that has always bothered me about the generic syntax for functions is how far the function’s name is from its parameters. There are probably reasons why the following might not work, but it could address my desire to keep the name of the thing close to the names of

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

Interesting, but I’m unsure if all of it is significantly better than just using the guard that is effectively inside of the operator/func that is being proposed: guard let value = Int("NotANumber") else { throw InitializerError.invalidString } It is only a couple of characters longer and

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

I'll throw another suggestion into the ring: private (scoped access) public (file access) internal (module access) external (infinity and beyond) l8r Sean Sent from my iPad > On Mar 25, 2016, at 8:57 PM, Ross O'Brien via swift-evolution > wrote: > > The specific

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

I know this is kind of winding down, and there seems to be a kind of begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still really don’t like it so I’m going to toss out my current favorite configuration and try to stop caring and defer to the core team to make an

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

>> None taken. However, most of the delegate concept of UIKit relies heavily on >> this "nonsensical" requirement. It is impossible for someone to implement a >> control in swift which is "in the spirit" of UIKit, meaning the control has >> a delegate, with several methods that share the same

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Some ideas I was thinking about for optional protocol functions was you’d declare it like this: protocol UIGestureRecognizerDelegate { optional func gestureRecognizerShouldBegin(gestureRecognizer: UIGestureRecognizer) -> Bool = true } If you put “optional” there, the compiler would

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Caveat: this is going to be strongly-worded; sorry in advance. I think > (no offense intended) it's a terrible idea. The whole notion of an > “optional requirement” is nonsensical to begin with, and the use of > optional protocol requirements encourages a style of programming that > lifts the

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I’ve wondered this as well. Using “self.dynamicType” is noisy and somewhat esoteric, and using “MyStruct.foo” is bad the moment you want to rename “MyStruct”. l8r Sean > On Apr 4, 2016, at 1:00 PM, Erica Sadun via swift-evolution > wrote: > > Are there reasons

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

This has been a very long and complex thread, but have some of these not-technically-mathy word pairs that have nice verb forms been considered: union -> combine / combining intersection -> intersect / intersecting symmetricDifference -> split / splitting Example: var allowedUsers = Set()

Re: [swift-evolution] What about a VBA style with Statement?

This pair works pretty well, too, if you don’t mind free functions: func with(inout this: T, @noescape using: inout T->Void) { using() } func with(this: T, @noescape using: T->Void) { using(this) } It works either with classes or mutable structs if you call it correctly and the type doesn’t

Re: [swift-evolution] Mutability for Foundation types in Swift

I don’t have anything significant to say other than that this is awesome. l8r Sean > On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution > wrote: > > Dear swift-evolution denizens, > > As you know from our announcement of Swift Open Source and our work

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Bikeshedding: Is it grammatically possible (or even desirable) to skip the “any” token and just have something like this: var view: init(view: ) {} if let mergedValue = button as? {} let a:

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

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 protocol itself doesn’t make sense to me. l8r Sean > On May 18, 2016, at 2:18 PM, Leonardo Pessoa via

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

I think it is too easy to just add warnings for warts and call it a day. These problems, IMO, should be addressed somehow eventually - but not with a warning. Either Swift decides these situations are errors and refuses to enable them at all, or the constructs involved should be carefully

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I think that, to me, the ability to allow trailing commas is linked with the ability to arbitrarily reorder defaulted parameters. If we retain arbitrary reordering of defaults (which I like and have taken advantage of), then we should allow trailing commas as well. Both of these features

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

I don’t know if this is a problem per-say, but very likely the API would often be used in code looking more like this: DispatchQueue.main.dispatchAsynch { // stuff } And maybe this is just me, but the double occurrence of the word “dispatch” in there rubs me the wrong way. :P This is

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution > wrote: > > Secondly it’s a very simple way of introducing new programmers to loops. It’s > IMHO more clear to a new programmer that repeat will just repeat indefinitely > vs while true. This point

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

Yep - same here. I think I was one of the first to propose we find some solution to this on the list back when it first started, and oddly enough, with more Swift experience comes less and less feeling of this even being a problem. I think as you start thinking more “in Swift” you start

Re: [swift-evolution] [proposal] Union Type

Cavet: I have not been following this, so probably someone has said this somewhere and flaws were pointed out. I don’t really understand the need for union types when you can have multiple methods of the same name that differ only by the type of their parameter: func something(value: A) {}

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

I’ve been wondering if shadowing variable names should just be an error. I know that it’s a very common pattern when unwrapping such as: if let thing = thing {} But that not only looks ugly, there’s often better ways to solve this and using different names there would also likely improve

Re: [swift-evolution] Dropping NS Prefix in Foundation

If I am coming to Swift as a new user (possibly as a first language, even) without any prior Objective-C experience and very little knowledge of the long history of Foundation, the NS prefix, etc, this is going to feel worse than a little out of place - it will feel downright wrong, broken, and

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

let myArray = Array([1, 2, 3, 4]) Is that an array with a single element that is an array, or is that a flat array with 4 numbers in it? There is no ambiguity here today - it’s an array with an array inside of it. How do you resolve this sort of situation after removing variadics? For the

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Heh.. actually there IS ambiguity today because that uses the SequenceType initializer and not the ArrayLiteralConvertible initializer.. so… hmm. :P Okay so maybe that was a terrible example. Still -1 for removing variadic. :P l8r Sean > On Apr 19, 2016, at 3:21 PM, Sean Heber

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 2:58 AM, Charlie Monroe via swift-evolution > wrote: > > An example to keep in mind: > > let dict: [String : String] = ... > if dict["key"] == "value" { // String? == String > // Do something > } > > If I understand correctly, when the

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

The only thing that really bugs me about subscript is that you declare it with (), but use it with []. I’ve never found the return indicator to be confusing here. I get the argument in favor of property-ness, though. Wouldn’t mind considering using square brackets instead, but perhaps that has

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

> The review of "SE-0121: Remove `Optional` Comparison Operators" begins now > and runs through July 19. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md > > * What is your evaluation

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution > wrote: > >> >> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >> wrote: >> >> -1 for the fact that if all devs can write working code, fewer can do it in >>

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

The trouble with this line of reasoning, IMO, is that it is what led to the floppy disk becoming the “universal” save icon for years and years. Apple has spent considerable effort in macOS and iOS trying to show that you don’t really need a save button at all most of the time - it turns out

Re: [swift-evolution] Setter methods for vars

Lens are a term from functional programming theory (I think largely Haskell in particular?). I don't know much about it, but here's somewhere to start: https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf l8r Sean Sent from my iPad > On Jun 28, 2016, at 6:11 PM, Michael Peternell via

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

IntegerLiteralExpressable? Does Apple employ any philosophers? We might need one... l8r Sean Sent from my iPad > On Jun 28, 2016, at 10:02 PM, Erica Sadun wrote: > > >> On Jun 28, 2016, at 8:08 PM, Sean Heber wrote: >> >> What about.. >> >>

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Arg. Dang it! Syntax.ExpressibleAsIntegerLiteral Syntax.FromIntegerLiteral Syntax.IntegerLiteralManifestation Syntax.GhostOfIntegerLiteral Syntax.FormerlyKnownAsIntegerLiteral l8r Sean Sent from my iPad On Jun 28, 2016, at 10:29 PM, Erica Sadun wrote: >> On Jun 28,

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Now that's just silly! l8r Sean Sent from my iPad > On Jun 28, 2016, at 10:49 PM, Greg Titus <g...@omnigroup.com> wrote: > > I’m honestly shocked that y’all (that I’ve seen) haven’t come up with > Syntax.LiterallyIntegerLiteral yet. > > > >> On Jun 28,

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

What about.. Syntax.ConvertibleFromIntegerLiteral etc.. l8r Sean Sent from my iPad > On Jun 28, 2016, at 8:52 PM, Matthew Johnson via swift-evolution > wrote: > > >>> On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

That’s pretty neat - although I’d inevitably forget and end up writing it with spaces between the “arguments" and the “operator”: someCollection[* … idx] But maybe even that could be made to work with some cleverness. l8r Sean > On Jul 5, 2016, at 1:45 PM, Dave Abrahams via swift-evolution

Re: [swift-evolution] Class mutation model and value-constrained protocols

>> One idea that Jordan and I have floated is that protocols with mutating >> methods should be constrained to applying to non-class types. That >> would be a step in the right direction, but, that still leaves cases >> like gg able to easily violate expectations when the protocol in >> question

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

> The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > I posted this somewhere

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

This mostly makes sense to me and it seems like mostly a good idea, but take this example: func doSomething(x: Int, y: Int) -> Bool { return true } let x = doSomething x(10, 10) Is it then legal to do this?: x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10) That would seem

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> The review of "SE-0110: Distinguish between single-tuple and > multiple-argument function types" begins now and runs through July 4. The > proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md > > *

Re: [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?

Makes sense to me! l8r Sean Sent from my iPad > On Jun 30, 2016, at 5:16 PM, Ayaka Nonaka via swift-evolution > wrote: > > Hi Swift community, > > I was wondering if bridging Objective-C’s @compatibility_alias to Swift’s > typealias is something that we have

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

+1 here, too. Looking like someone needs to write a full proposal! :P l8r Sean > On Jul 1, 2016, at 9:11 AM, Tony Allevato via swift-evolution > wrote: > > +1. I've had to do this a couple times and ended up wrapping them in string > interpolations, which makes me

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

Minor, but I think I'd be onboard as well. Once proposed (and assuming it was approved), this would likely be deferred until post Swift 3 since it’s additive. l8r Sean > On Jul 1, 2016, at 2:38 AM, Diego Barros via swift-evolution > wrote: > > When you want a

Re: [swift-evolution] [Proposal] Sealed classes by default

Coming in late on this, but here’s my take guided by the principal of least surprise (according to me): - everything is sealed within its module by default, no keyword - use “public” to mean “exported out of the module, subclass/overridable” - use “public(final)” to mean “exported out of the

Re: [swift-evolution] [Proposal] Sealed classes by default

Ok, I suppose that this design *basically* undoes the sealed by default thing, doesn’t it? :P lol. One of those days, I guess.. Sigh. Crawling away… l8r Sean > On Jul 1, 2016, at 1:16 PM, Sean Heber wrote: > > Coming in late on this, but here’s my take guided by the

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

Another issue here (perhaps) is, what if you misspelled the associated type when you attempted to typealias it manually? Would it not just make a new typealias with your misspelled name and then, potentially, you’d get an error or would something end up working but in unexpected ways? Would the

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 29, 2016, at 10:08 AM, David Hart wrote: >> >> Sorry if I wasn’t expressing myself well enough. In my original email, I >> said that: >> >> > The new

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

> Agreed. I'd have to be convinced that having aliases provide overwhelming > wins at the call site that could not be achieved through renaming. Although > aliasing could be very neat in certain circumstances, I fear that admitting > such a facility to the language is an "out" that would

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

sing, and increase > the difficulty of learning the APIs and QuickHelp is not always there to > help. To me, they sound like a convenience for the code writer but a nuisance > of the reader. And Swift has always tried to improve its readability over its > writability. > > On 2

Re: [swift-evolution] Removing enumerated?

In practical usage, I rarely use enumerated() - and almost every time I do use it, I end up refactoring 20 minutes later to not use it. Maybe that's just me, though. I imagine this isn’t helpful feedback. :P But perhaps we (or I) need to understand what it’s being used for or if there’s a

Re: [swift-evolution] for-else syntax

I usually use guard (or sometimes if) and an early return: func run() { guard !names.isEmpty else { /* stuff */ return } /* stuff with names */ } l8r Sean > On Feb 1, 2017, at 12:18 PM, Nicolas Fezans via swift-evolution > wrote: > > I tend to

  1   2   >