- 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 ou
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, classes,
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
p
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.
Copy-pasti
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 'con
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 th
(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 exi
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
> https://gi
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 value
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 being
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 dif
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
'appliedBefore'
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 y
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?
Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, you can do this already:
>> let words = "rats live on no evi
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
o
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 numerical
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 prope
+1 on mapValues.
DictionaryLiteral already throws an exception if it includes duplicate
keys, so I'd expect mapKeys to throw an error if multiple source keys
mapped to the same destination key.
On Wed, Apr 13, 2016 at 11:28 AM, Miguel Angel Quinones via swift-evolution
wrote:
> I'm +1 for addin
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
14, 2016 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 1
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() ->
Shape'
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 O’Brien’s post:
> > As of Swift 2.2, if a variable has a c
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
pro
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
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 5,
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 accept
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
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
In reply to:
Why would you want to add all of these different formats where only one
could serve them all. This is redundant in my opinion.
`struct<>` and `enum<>` would have same rules, only the first element would
be a different value-type. I might consider this as an alternative.
Correct me i
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
th
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" +
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
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:
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 writing
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
>
>
> 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
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
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 th
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, 20
There's a problem here because associated types aren't the same as generics.
I've been looking this up a lot recently because I've been trying to create
a delegate protocol for a generic type. The GenericType requires a
GenericTypeDelegate and Swift 2 protocols just don't support those yet;
the be
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.
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 thi
Thoughts:
Here are the first two ideas I had regarding generic 'access' symbols.
"public" -> symbol visible outside the current module
"internal" -> symbol visible within the current module
"restricted" -> symbol visible within the current file
"private" -> symbol visible within the current declar
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
te(module) and private(file) are relatively long, but the
>>longest – private(module) – is rarely used (outside the standard
>>library) 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
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 to
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. I
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
functio
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:
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.
O
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 'fil
Well, several prominent voices seem to think that 'private' is "intuitively
obvious" when it refers to declaration-level scope, so I didn't argue that
point. I still happen to disagree; I would add 'privatetodeclaration' to
'privatetomodule' and 'privatetofile', which would solve that
conversationa
The specific meaning of 'public' and 'private' in programming languages
refers to type-based symbol visibility. I'm thinking of C++, C#, Java and
Objective C; their 'public' is Swift's 'internal'. They have no equivalent
to Swift's 'public'. Swift has no equivalent to their 'private'.
Possibly my
tected' to mean 'local'?
>
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.
>
>
> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote
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', program
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 'priv
If 'knowing from the context that it only applies to a certain scope' is
really that helpful, then let's make it as simple as we can:
'firstprivate', 'secondprivate', 'thirdprivate', 'fourthprivate'. That's an
easily extensible system: if we need a new level, we add 'fifthprivate'.
Then we re-learn
That depends how you define 'namespace'. A module is a set of files. Is a
namespace a set of files, a subset of the module's set?
If yes, namespace fits in with the hierarchy: 'public', 'module private',
'namespace private', 'file private', 'scope private'. Easy.
If no, then I'm guessing it means
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 it.
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 swift-evolu
> 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.
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 acc
"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 tha
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
thos
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 were
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 relat
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 th
It's probably appropriate. Given that, in this example, Bar implicitly
unifies its generic constraint T with Foo's associatedtype T (or,
typealiases T with T), you need to be at least a little careful how you
name your generic constraints.
protocol Foo
{
associatedtype T
}
struct Bar : Foo
{
I'm hoping this extends to type values.
struct StructWithClosure
{
let closure : (lhs: Element, rhs:Element) -> Range where
Element : Incrementable, Comparable
}
or for that matter, protocol values:
struct StructWithIntCollectionType
{
let collection : C where C : CollectionType, C.Elemen
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. There
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 sometimes
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
>
>
> This is what I had in mind; i.e- you don't *have* to parameterise
> private, you'd only do it if you want something other than the default.
>
> As for something with both public and private modifiers (only really
> applies to properties I think?) I think it's fine to just declare each
> separ
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
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
O
76 matches
Mail list logo