Re: [swift-evolution] [Proposal] Random Unification

When Apple added GameplayKit to iOS, they added randomisation functions. Could that implementation be repeated in Swift Foundation? On Mon, Sep 11, 2017 at 2:48 AM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Hello, > > I have an implementation for reference >

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

(0..<3).map{ _ in UIView() } - map already returns an Array. Array((0..<3).map{ _ in UIView() }) is redundant. I've fallen foul before, of trying to create an array of six buttons and getting an array of one button six times; I think that should be easier. But if each button corresponds to an

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I would like to add something to this discussion on casting generics. I think there is a temptation to think of generic types as having a protocol-like aspect. If String conforms to Any, then a [String] ought to conform to [Any]; the current scope may think of the variable as being a [Any] even

Re: [swift-evolution] Variable with generic protocol type

As I understand it, and someone please correct me if I'm wrong, you've just described *existentials*, which Swift doesn't fully support yet but which are on the Generics Manifesto. It would be nice to declare or cast a variable as 'conforms to protocol X with associated type known to be Y' or

[swift-evolution] (Pitch) Conformance Regions

This idea was had during the SE-0159 Review regarding removing fileprivate and I'm creating a new discussion thread for its consideration. It's neither in favour of nor against keeping fileprivate, but is intended to address an idiom which has led to some resentment against fileprivate.

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

I'm considering this from a different angle. When we declare a type, we declare properties and functions which that type has. When we extend a type, we add functions to the type. (I'm including computed properties in this.) It's become an idiom of Swift to declare an extension to a type for each

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

We should be clear about this, because it seems to me that this is the source of the 'cognitive load' problem: Following Alternative 3, private properties in scopes, would become "scoped". fileprivate properties in or out of scopes would become "private". private types, such as protocols,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? In general: against. Scope-based access is useful and should not be removed. The fileprivate keyword is long and awkward to say, but unambiguous in purpose. 'Private' is ambiguous, referring to scope-based access inside a scope but file-based access

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

I could see a purpose for identifiers which started numbers but weren't entirely numerical. e.g. enum Dimensions { case `2D`, `3D` } enum DiceRoll { case d6, `2d6` } func roll(dice: DiceRoll) -> Int { ... } roll(.`2d6`) I'm not sure I see one for identifiers which are entirely numerical. Ross

Re: [swift-evolution] [Pitch] Allow trailing argument labels

I'd like to see this, particularly in initialisers. Objective C can have '- (instanceType) init' and '- (instanceType) initWithQualifier', where Swift can only have 'init()'. On Wed, Feb 22, 2017 at 10:24 AM, Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > I'd like to

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

Let's start with: I much prefer including the word 'file' in the file access level, to not including it. The bikeshedding discussions proposed too many permutations of 'public' 'external' 'internal' 'private' for me, not to mention the potential additions of 'secret', 'hidden', 'closed'... I think

Re: [swift-evolution] final + lazy + fileprivate modifiers

My two cents: I like that Swift has a way of restricting access to some properties and functions to just the scope in which they're declared (Swift 3 private). At the moment I tend to use the Swift idiom of declaring a type, and then declaring an extension each protocol conformance, and

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I'm in favour of 'pure' functions, because they're a way of reducing the repetition of the kind of calculations you might want to perform in initialisers to convert argument values into property values. I don't know why "the function must have a return type" is seen as a requirement, though.

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

There has been a little discussion on this before, and I think there's a need for something along these lines - I've written code where I've used 'guard' to ensure that an Int was within a certain range, and then performed a switch on the Int, requiring an ugly-looking 'default: fatalError()' at

Re: [swift-evolution] [Discussion] Breaking precedence

Assignment has the lowest precedence. 'x = condition ? y : z' doesn't make sense if assignment is resolved before the ternary; the compiler would complain that perhaps you meant '==' instead of '='. There was an idea ages ago for essentially a 'switch expression' which was effectively ternary for

Re: [swift-evolution] End of source-breaking changes for Swift 3

> > > This would imply, that if a decision is made, which in a later and changed > context proves to be a bad one, would be irreversible? > Better turn half way than to err in continuing. > Or, one decides to go diving, but arriving at the location, notice that > the water is full of sharks? Still

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

This might be a radical suggestion ... or possibly a naive or unoriginal one, I'll find out once I suggest it. Swift took the bold step of establishing optionals as a central type, rather than assigning dual meanings to 'default' values such as zero or false. Recognising the concept of not having

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

I think we're making incremental progress here. The idea of declaring a property which inherited from a given class and conformed to given protocols has definitely been discussed, but hasn't been reviewed (I don't know offhand whether it's scheduled or even formally written up). The idea of

Re: [swift-evolution] Returning nothing

There's a difference between returning a void type and returning nothing. An instance of Void is a catch-all 'something' which conforms to no protocols, which can be quite useful with generic types. On Thu, Jul 21, 2016 at 5:59 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

Ted: here's the counter-challenge. func emptyStringPrefixChallenge(inputString: String) -> Bool { let prefixedString = "" + inputString return (prefixedString == inputString) } The challenge: find a value for inputString such that this function returns false. Because otherwise, if it returns

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

To the question of whether any given string has the empty string as prefix: yes it does. This is a correct answer, and returning true is a correct behaviour. To the question of how many times the empty string occurs in a string: yes, this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" +

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I'm in favour of this concept being available in Swift, but it does need to make a clear distinction somewhere between a case which matches anything (and can catch any fallthrough/continue) and a case which matches none of the above. I don't know whether we need to introduce an explicit term for

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

I've got another suggestion for the bike shedding, and a question. The naming suggestion: why not simply 'precedes' and 'succeeds'? This avoids the conjoined words problem. Then you're just writing 'Multiplication { succeeds: Exponentiation, precedes: Addition }'. The question: this syntax lets

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

I agree that the colon-separated syntax looks cleaner. However, I agree with Xiaodi about the stronger/weaker terms being less clear (if only because I associate those terms with memory management in Swift, not operator precedence). My personal preference would be for something like

Re: [swift-evolution] Access modifier blocks

Your style may vary, but in my experience the access level of two functions has very little effect on how they should be grouped. Let's take an example: a class with two init functions. (If you want a concrete example: a subclass of UIView has init(frame) and init(coder)). While the inits take

[swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

Given a protocol with an associated type: protocol Foo { associatedtype Bar } it should be possible to define a protocol conforming to Foo, for which Bar can be typealiased: protocol IntFoo : Foo { typealias Bar = Int } such that all conformers to IntFoo now have an associatedtype Bar

Re: [swift-evolution] [Proposal] Enums with static stored properties foreach case

Perhaps there's an argument to be made for a sort of 'enumDictionary' type - a dictionary whose keys are all the cases of an enum, and is thus guaranteed to produce a value. I think the question I have is how you'd access the values, syntactically. To use the Planet example, if '.earth' is a

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

The immediate problem I see with your suggestion is the reason why optionals in Swift are pretty damned awesome: Swift doesn't have default values. A Bool is not false by default; the Swift compiler will complain if you don't initialise a Bool variable with a value, one way or the other. The idea

Re: [swift-evolution] [proposal] extra if syntax

In your example: a = 5 if b == x What value is assigned to 'a' if 'b' and 'x' are not equal? On Tue, May 10, 2016 at 7:10 PM, MobileSoft (Piotr) via swift-evolution < swift-evolution@swift.org> wrote: > I think that should be added new ‘postfix’ if syntax: > a = 5 if b == x > > the code will be

Re: [swift-evolution] [Opinion] Thoughts about the SE-0025 (Scoped Access Level) proposal

When you say you missed all the discussions and threads... you missed probably the longest bikeshedding discussion we've had on Swift Evolution so far. First: no-one's ruled out a 'protected' access level yet. Equally, as far as I recall, it hasn't been presented for review yet. It's neither

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

I was about to provide this, but Krzysztof's example is more compact than mine: enum Coin { case heads case tails } var result: Coin? switch result { case .Some(.heads): print("heads") case .Some(.tails): print("tails") case nil: print("not yet flipped") // exhaustive } On Thu, May

Re: [swift-evolution] Carriage Return in Collection Array Literal Initializer

There was a discussion some time ago about making the comma of the last entry optional, because adding entries meant changing more than one line of code and this annoyed users of version control systems. This is an elegant approach to that problem. I don't know if it's a practical approach for the

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

Thanks Gwendal, that makes sense - for the case where Shape is a protocol. Since the OP wasn't clear about it, I tried the original example with both the cases where Shape was declared as a protocol (i.e. Circle conforms) and where Shape was declared as a class (i.e. Circle inherits). The same

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

You may have to explain that metaphor (or link to an explanation) - what is 'trampoline' data? On Mon, Apr 18, 2016 at 11:11 AM, Gwendal Roué wrote: > > > Le 18 avr. 2016 à 12:01, Yogev Sitton a écrit : > > > > I’m referring you to Ross

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a closure of type () -> Circle would be considered a match. If a class implements 'func make() -> Shape', a subclass implementing 'func make() -> Circle' has to override. However, if a protocol requires a 'func make() ->

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

at 4:29 PM, Vladimir.S wrote: > +1. This will make our life easier, it is clear and explicit about the > result. > > I assume that there must be a constrain : you can use in init(...) only > props introduced in the same class, not in parent class. > > > On 14.04.2016 17:32, Ross

[swift-evolution] [Pitch] Unifying init parameters with properties

This is a common pattern for initialisers at the moment: class Foo { let foo : String let bar : String let barCount : Int let baz : Int init(foo: String, bar: String, baz: Int) { self.foo = foo self.bar = bar self.baz = baz barCount = bar.characters.count } } This involves a lot of

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly 'iterate' rather than 'loop'?) I've not missed the C-style for-loop so I've not argued to keep it, but recently I was refactoring a function which started with a UIView and iterated up the hierarchy through the superview

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

Your pointing to two mutually exclusive protocols proves the point. If I want to write a generic function for a numerical type which can be added, I can't just require that the type conforms to IntegerArithmeticType because that excludes all the floating point types. Protocols for various

Re: [swift-evolution] [Proposal] Custom operators

If I want to define a new operator, it seems like an unnecessary overhead to have to immediately decide which precedence group it should belong to before it can be used (assuming it doesn't interact with other operators). At the moment, new operators are implicitly assigned a 'default' precedence

Re: [swift-evolution] Shortcut for creating arrays

Well, you can do this already: let words = "rats live on no evil star".componentsSeparatedByString(" ") so I don't know how much a shortcut is needed. And given '%w' would currently be impossible in Swift as an operator containing a letter, is there a Swiftier function name or operator for this?

Re: [swift-evolution] Generic Alaises

It's not the same topic. Let's take an example: suppose we have a data structure for a graph of nodes and edges, where the nodes and edges are indexed and both have values. So we have a Graph. Now suppose we want a shortest path from one node to another, and we have a data structure to represent

Re: [swift-evolution] [Proposal] Custom operators

How is a non-transitive relation different from a conflict? If we use: #precedence(+, lessThan: *) #precedence(*, lessThan: ^) #precedence(^, lessThan: +) Surely that should be an error, even with none of the operators actually used? The compiler would be asked to verify two things: that the

Re: [swift-evolution] [Proposal] Custom operators

There is a problem here of duplicated operators or custom precedence, and how that gets passed between modules. Assume there are three modules, A, B and C. B defines a custom operator **. A and C each define a custom operator ++, and their meanings are different (though, even if their meanings

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

Because you're coming to the discussion late, the arguments you're making are a little out of date. It's no longer a case of not removing these features. It's now a case of having a compelling reason to put them back. I trust you've read the proposals that were put forward. For the benefit of

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

"or within my whole program (external)". That caused a double-take on its own. external things are not within, they are outside. 'external' could be a replacement term for 'public', not for 'internal'. This may well be a subjective thing, but I don't think in files, I think in modules because

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

A new type is implicitly internal to a module. Implicitly specifying it as 'external' is just plain confusing. On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > I know this is kind of winding down, and there seems to be a kind of > begrudging

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

> public > internal > interfile > private Linguistically, I really like this direction. 'interfile' is one word, it reads as an adjective, it can be used in conversation (this has interfile visibility), and it's clear about where its visibility ends. It just doesn't mean what you think it means.

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

Damn, and I thought it was clear all this time that 'private(module)', or 'private(#module)', or 'moduleprivate', meant that the symbol is visible only inside the module. It's always been a suggested replacement specifier for 'internal'. On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via

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

So, just so I'm understanding correctly what the new system would be (taking into account Chris Lattner's comments). A symbol specified as 'public' is visible outside the module. A symbol with no specifier, or specified as 'moduleprivate', is visible only within the module, but anywhere within

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

How is flexibility desirable? Why is it important to me, if I decide that a given class should only be visible at 'internal' scope, that the meaning of 'internal' should be subject to change in future versions of Swift? 'Once you know its meaning' should mean once! Right now, I use the word

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

Ilya said: > "public", "protected", and "private" have a very well defined meaning in OOP. We shouldn't redefine them without a good reason. I agree. Swift has a scope-based visibility system, not a type-based visibility system, but because Swift redefines the terms 'public' and 'private',

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

Well... how about we reverse the terms: call them 'privatetomodule' and 'privatetofile'. This is 'private(module)' and 'private(file)' but fitting the all lower-case style. It puts 'private' first (and when you use the keyword, 'private' is the bit you want to start with more than 'module' or

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

I agree that 'private' still feels too subjective on its own. It's intuitively 'not public'; it's not intuitively the access term for 'declaration only'. I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd just prefer a corresponding scopeprivate or declarationprivate.

Re: [swift-evolution] ++ and --

I'd be willing to keep "++" and "--" if they stopped having a return type. "x++" is fine; "let y = x++" is where we lose clarity, so I'd much prefer to see that expressed as "let y = x + 1; x++". On Wed, Mar 23, 2016 at 1:10 PM, Ergin Bilgin via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

I recently had the misfortune of deleting what turned out to be a necessary function, because it was an optional requirement of a protocol and wasn't being called by any code in the project, so I would sympathise with this. On the other hand I've also written protocols composed entirely of

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

But the discussion is no longer about 'do we really need to take this feature out?'. The feature is already out. It's deprecated in Swift 2.2. The discussion is 'is there a compelling reason to put it back in again?'. We still have for-in loops. We still have repeat while. We still have forEach.

Re: [swift-evolution] Fwd: [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

At the moment I'm considering Jordan's point: "(IIRC last time we got to "it's required if the member is in the same module, but allowed to be absent otherwise", which is fairly reasonable but probably still needs to be thought through.)" Taking my example: Int, Int16, Int32, Int64 etc. conform

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

as it's the default. Most uses of the old private are more >>appropriately done using the new private, so private(file) would >>likely be used less than private. >>- The scheme expands very well to named submodules, e.g. if you have >>a submodule named model you might li

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

It's occurring to me, reading these recent posts, that we have two orthogonal systems of access levels. Swift's current access system is file based; a project file decides which files comprise a module, and the terms 'public', 'internal' and 'private' determine whether a property is accessible to

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

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

[swift-evolution] Idea: delegates as protocols and property types with specialised behaviours.

At the moment, the delegate pattern is just one use of protocols. We create a protocol with a set of declared functions, implemented either in a protocol extension or in the conforming type - the delegate - and another type calls functions of its delegate, notifying them when certain events occur.

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

I would much prefer one of the longer terms such as 'associatedtype' to 'type'. The simple reason why: I've been using a lot of generics for a while and I still find it tricky. I want a term I can type into a search engine and expect results for, and 'type's too common for that. On Tue, Dec 22,