[swift-evolution] Support for newtype feature/typesafe calculations

[Grzegorz Adam Hankiewicz via swift-evolution]

Hello, newcomer here.

The other day I was reading about 
https://www.reddit.com/r/swift/comments/3zbk64/type_math/ and given the verbose 
solutions decided to pitch a possible language improvement. But after reading 
through the archives it seems that this idea has already been pitched before:

* Proposal: newtype feature for creating brand new types from existing types

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001826.html

Some time later:

* Epic: Typesafe calculations

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004735.html

Since this is already known I would like to talk about this potential feature 
in order to address the perceived lack of community interest.

Recently I’ve been bitten by a lack of this feature for code dealing with 
database serialisation. If a database table is modelled as an object it will 
most likely use integers or longs to represent primary and foreign keys. An 
example would be:

struct SomeTable {
var primaryKey: Int64
var otherTableForeignKey: Int64
var yeatAnotherForeginKey: Int64
}

Unfortunately the types can be mixed, one can assign the value from 
otherTableForeignKey to primaryKey without impunity. Using the reddit proposed 
struct as separate type would help here:

public struct RefTablePk {
private let value: Int64
}

public struct SomeTablePk {
private let value: Int64
}

struct RefTable {
var primaryKey: RefTablePk
}

struct SomeTable {
var primaryKey = SomeTablePk(value: 0)
var otherTableForeignKey = RefTablePk(value: 0)
}

var a = SomeTable()
a.primaryKey = SomeTablePk(value: 3)
a.otherTableForeignKey = a.primaryKey // Fails, good!
print(a.primaryKey.value)

So far so good. The solution gets more hairy when one attempts to use such fake 
types for mathematical operations because the new type doesn’t inherit possible 
operations done on the parent type it is based of:

public struct Euros {
private let value: Double
}

public struct Dollars {
private let value: Double
}

var account = Euros(value: 100)
var bill = Euros(value: 42)
account = account - bill

The last line won’t compile: Binary operator ‘-‘ cannot be applied to two 
‘Euros’ operands. The immediate solution would be to add variants of all the 
usual operators for every type, which quickly gets tedious and verbose. On top 
of this, each *new* type is generating code, which is actually not desirable. 
The ideal would be for the compiler to pretend Euros or RefTablePk are 
different types, yet use their parent type at the binary level. This needs a 
specific syntax to teach the compiler which existing methods/operations are 
allowed on the new fake types and which aren’t. These new distinct types would 
*borrow* previous implementations.

Other examples of possible use for such fake types (note again: these exist 
only at compilation time and generate no extra code) would be user input 
validation. Strings coming from *the exterior* (whatever that might be) could 
use a distinct type of TaintedString instead of the usual String, and would 
require a validation or converter function to produce a correct String, or 
maybe a ValidatedString for better distinction. Similarly for a security 
library it would be useful to mark Strings as encrypted. The EncryptedString 
would be tracked by the compiler to prevent mistakes or uses where plaintext 
strings are expected. One bug I recently had the pleasure to solve was mixing 
time units, some APIs use seconds, other use milliseconds, both store the 
values as longs. The *fix* was to wrap all primitive type access inside objects 
with explicit methods having the unit in their signature. Effective, but 
tedious and verbose.

The typealias jumped out of the swift language documentation while I was 
reading it, but it is actually the opposite of the desired behaviour. The 
current type alias doesn’t prevent one from mixing these new fake types so it 
has effectively the same value as a user comment. Also, having seen 
https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
 it seems that the keyword won’t be used any more, plus it would be convenient 
to invent a new one to avoid migration mistakes.

Examples I know of this feature in other languages and/or implementations which 
can be used for reference/inspiration:

- C++. I asked 
http://stackoverflow.com/questions/23726038/how-can-i-create-a-new-primitive-type-using-c11-style-strong-typedefs
 while following a talk by Bjarne Stroustrup and some of the answers include 
using boost units 
(http://www.boost.org/doc/libs/1_60_0/doc/html/boost_units/Units.html) to 
alleviate writing the required boilerplate code. The library was already 
mentioned here as reference in previous 

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

[Sean Heber via swift-evolution]

> 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: 0xFF

This is my favorite and addresses the sort of situations I’ve run into where 
using a switch statement seems unnecessarily bulky. I’d like to see this as a 
proposal because it’d be a very useful construct on its own.

Using “else” would be maybe a little odd when paired with cases, but it also 
doesn’t look bad and, I think, could be argued that it makes sense in the 
context of an expression:

let x = color ?
  case .Red: 0xFF
  case .Green: 0x00FF00
  case .Blue: 0xFF
  else: 0xFF

Then you could say this when using a boolean:

let x = something ? case true: thing() else: otherThing()

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 pretty terse and 
the addition of “else” in there makes the entire expression stand out a bit 
more than traditional ternary expressions which, I think, addresses one of the 
complaints there.

l8r
Sean

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 10:51 AM, Sean Heber  wrote:
> 
>>> 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 pretty 
>>> terse and the addition of “else” in there makes the entire expression stand 
>>> out a bit more than traditional ternary expressions which, I think, 
>>> addresses one of the complaints there.
>> 
>> I do not like this idea.  I think a case expression should follow the case 
>> statement where a corresponding keyword is used.  If you want to make this 
>> more like ternary we should just allow `:` without any keyword for the 
>> default clause.
>> 
>> Your suggestion that this would replace ternary and require an `else:` 
>> instead of `:` is going to be a non-starter. You may want to read the 
>> “frequently proposed changes” document as it explains why such a change 
>> won’t happen.
> 
> I don’t see anything in that document that says that replacing ‘:' with 
> ‘else:' in a ternary is necessarily a nonstarter - the ternary feature would 
> still exist, it would only be *slightly* more verbose. The document says that 
> one that is “better enough” hasn’t been found yet but it doesn’t read to me 
> that it is a declared fact that “better enough” will *never* happen.

The concise nature of ternary is considered one of its big advantages.  I don’t 
think any alternatives that require 3x more characters are going to be 
seriously considered.  But who knows, I might be wrong.

> 
> In any case, replacing ternary isn’t really something I care about - but I do 
> want switch-as-expression since I’ve run into that a *lot* in one of my 
> current projects where I adopted enums quite heavily. My suggestion was only 
> that such a construct *could* be massaged to also cover ternary and thus 
> could be considered a single construct that solved two “problems”: changing 
> ternary to stand out slightly more, and getting switch-as-expression at the 
> same time.

I agree that a case expression would be a good thing.  I think we are more 
likely to see a proposal for that adopted if it doesn’t include any changes to 
ternary.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for newtype feature/typesafe calculations

[Jeremy Pereira via swift-evolution]

I’m not saying your proposal would not be useful, but in the case of all of 
your examples, there are solutions that can be implemented now that might be 
better than just creating a new-type-but-exactly-the-same.

> On 5 Jan 2016, at 16:11, Grzegorz Adam Hankiewicz via swift-evolution 
>  wrote:
> 
> The other day I was reading about 
> https://www.reddit.com/r/swift/comments/3zbk64/type_math/

The idea of having a different type for each unit of distance is just wrong. 
You have one type for Distance with a value in a canonical unit and properties 
that extract the value in different units e.g

struct Distance
{
let m: Double // SI unit of distance
var km: Double { return m / 1000 }
var cm: Double { return m * 100 }
var miles: Double { return km * 0.62 }
}

Then you only need one set of addition and subtraction operators. You would 
also have multiplication by a dimensionless constant yielding a Distance and 
multiplication of two Distances yielding an Area.


> struct SomeTable {
>var primaryKey: Int64
>var otherTableForeignKey: Int64
>var yeatAnotherForeginKey: Int64
> }
> 
> Unfortunately the types can be mixed, one can assign the value from 
> otherTableForeignKey to primaryKey without impunity.
> Using the reddit proposed struct as separate type would help here:
> 
>public struct RefTablePk {
>private let value: Int64
>}
> 
>public struct SomeTablePk {
>private let value: Int64
>}
> 
>struct RefTable {
>var primaryKey: RefTablePk
>}
> 
>struct SomeTable {
>var primaryKey = SomeTablePk(value: 0)
>var otherTableForeignKey = RefTablePk(value: 0)
>}
> 
>var a = SomeTable()
>a.primaryKey = SomeTablePk(value: 3)
>a.otherTableForeignKey = a.primaryKey // Fails, good!
>print(a.primaryKey.value)

That all looks fine except, why not take advantage of nested types:

struct SomeTable
{
struct PrimaryKey { let value: Int }

var primaryKey: PrimaryKey
var refTableId: RefTable.PrimaryKey
}

> 
> So far so good. The solution gets more hairy when one attempts to use such 
> fake types for mathematical operations

Why would you want to do mathematical operations on the primary key of a table? 
Primary keys obviously need to be Equatable and possibly Comparable (except 
what if the database uses a GUID as its key) but that is about it.

>public struct Euros {
>private let value: Double
>}
> 
>public struct Dollars {
>private let value: Double
>}
> 
>var account = Euros(value: 100)
>var bill = Euros(value: 42)
>account = account - bill
> 
> The last line won’t compile: Binary operator ‘-‘ cannot be applied to two 
> ‘Euros’ operands.

How about a Currency protocol?

protocol Currency
{
// value in smallest unit of currency e.g. EUR = cents, GBP = pence
var rawValue: Int64 { get }
init(rawValue: Int64)
}

func -(a: T, b: T) -> T
{
return T(rawValue: a.rawValue - b.rawValue)
}

struct EUR: Currency
{
var rawValue: Int64
}

struct USD: Currency
{
var rawValue: Int64
}

let foo = EUR(rawValue: 2000)
let bar = EUR(rawValue: 1000)

let baz = foo - bar // compiles

let whizz = USD(rawValue: 4000)

let biz = baz - whizz // error: binary operator '-' cannot be applied to 
operands of type 'EUR' and 'USD'

Only one - operator needs to be defined for all currencies and the fact that 
EUR and USD are intended to model currencies is self documenting.

So I don’t think any of your examples are compelling evidence for your 
proposal. That’s not to say there are not good reasons for it, I just haven’t 
seen them yet.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Florian Bachmann via swift-evolution]

Hey Vincent,
good proposal, love to see this in production. Better collection search
would become quite handy :-)

regards,
Flori

On Mon, Jan 4, 2016 at 4:13 PM, Vincent Esche via swift-evolution <
swift-evolution@swift.org> wrote:

> After having had this code laying around on my Mac since 6/26/15 (waiting
> for Swift to go open source)
> I figured it’s about damn time I submit the actual RFC for it. So without
> further ado…
>
> One of the areas where Swift’s stdlib is still quite lacking is searching.
> Which is a shame as searching (along with indexing) might be among
> the most important tasks of computer science/software development.
> One might not need fast collection searches for writing a banal fart or
> flashlight app,
> but almost every other app is likely to benefit from having a proper
> searching API.
>
> So I’d like to fix that.
>
> Attached you find a full RFC along with the full and functional source
> code to make it happen.
>
> I’d love to hear your opinion on this and will be more than happy to
> answer questions.
>
> Rendered Version + Full Implementation:
> https://gist.github.com/regexident/2b7531bd748f57679671
> (The code is tested using Quick/Nimble. Tests would thus have to be ported
> to Swift’s XCTest.)
>
> - Vincent
>
> Markdown-dump for
>
> # Improved Collection Search
>
> * Proposal: [SE-](
> https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
> )
> * Author(s): [Vincent Esche](https://github.com/regexident)
> * Status: **Review**
> * Review manager: TBD
>
> ## Introduction
>
> This RFC proposes an extension to the currently rather limited and linear
> searching API of `CollectionType`, that is `indexOf(element:)` and
> `indexOf(predicate:)`.
> It proposes the backwards-compatible refactoring of those existing methods
> as well as the introduction of a view-based ensemble of methods for
> efficient binary-search.
>
> Swift-evolution thread: [link to the discussion thread for that proposal](
> https://lists.swift.org/pipermail/swift-evolution)
>
> ## Motivation
>
> Indexing of and searching in data is a big deal in software development.
> As such it is crucial to have capable means of doing so in a language that
> aspires to be a highly performant programming language.
>
> Swift's current API for searching is basically limited to these two
> methods on `CollectionType`:
>
> > ```swift
> > func indexOf(element: Self.Generator.Element) -> Self.Index?
> > ```
> > Returns the first index where value appears in self or nil if value is
> not found.
> >
> > **Complexity**: `O(self.count)`.
>
> and:
>
> > ```swift
> > func indexOf(@noescape predicate: (Self.Generator.Element) throws ->
> Bool) rethrows -> Self.Index?
> > ```
> > Returns the first index where predicate returns true for the
> corresponding value, or nil if such value is not found.
> >
> > **Complexity**: `O(self.count)`.
>
> The author sees a couple of issue with these two methods:
>
> 1. They do not provide an option for restricting the "haystack" to a
> certain `range` of `self`.
> 2. They do not provide a fast (`O(log2(self.count))`) path for sorted
> collections.
> 3. They should not be limited to `CollectionType` but instead be moved to
> `Indexable`.
>
> In many situations it is desirable to perform fast searches on sorted
> collections instead of having to fall back to naïve linear searches.
>
> Further more while a single `index` might be the most common subject of
> interest, there are many scenarios where a `range` or `count` of matches
> are of more use.
>
> And anyone who is writing a custom ordered collection type will eventually
> want to find the insertion index for a given element and will thus end up
> writing some variant of `lowerBoundOf(…)` or `upperBoundOf(…)` (upon which
> all the other methods can be implemented, actually).
>
> ## Proposed solution
>
> The author proposes:
>
> 1. A backwards-compatible refactoring of `CollectionType.indices`, moving
> it to `Indexable`.
>
> 2. A backwards-compatible refactoring of `indexOf(…)` (adding optional
> `range:` and moving it to `Indexable`).
>
> 3. The addition of `rangeOf(…)`, `countOf(…)` and `isSorted(…)` to
> `Indexable` with a TIME complexity of `O(self.count)`.
>
> 4. The introduction of a `BinarySearchView` on `Indexable`, allowing for
> fast (`O(log2(self.count))`) searches on `Indexable` via `indexOf(…)`,
> `rangeOf(…)`, `countOf(…)`, `lowerBoundOf(…)`, `upperBoundOf(…)` without
> cluttering `Indexable`'s interface.
>
> ## Detailed design
>
> ### `CollectionType.indices`:
>
> The author proposes the relocation of `.indices` from `CollectionType` to
> `Indexable`:
>
> ```swift
> extension Indexable {
> /// Return the range of valid index values.
> ///
> /// The result's `endIndex` is the same as that of `self`.  Because
> /// `Range` is half-open, iterating the values of the result produces
> /// all valid subscript arguments for `self`, omitting its `endIndex`.
> public var indices: Range { 

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

[Sean Heber via swift-evolution]

>> 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 pretty terse and 
>> the addition of “else” in there makes the entire expression stand out a bit 
>> more than traditional ternary expressions which, I think, addresses one of 
>> the complaints there.
> 
> I do not like this idea.  I think a case expression should follow the case 
> statement where a corresponding keyword is used.  If you want to make this 
> more like ternary we should just allow `:` without any keyword for the 
> default clause.
> 
> Your suggestion that this would replace ternary and require an `else:` 
> instead of `:` is going to be a non-starter.  You may want to read the 
> “frequently proposed changes” document as it explains why such a change won’t 
> happen.

I don’t see anything in that document that says that replacing ‘:' with ‘else:' 
in a ternary is necessarily a nonstarter - the ternary feature would still 
exist, it would only be *slightly* more verbose. The document says that one 
that is “better enough” hasn’t been found yet but it doesn’t read to me that it 
is a declared fact that “better enough” will *never* happen.

In any case, replacing ternary isn’t really something I care about - but I do 
want switch-as-expression since I’ve run into that a *lot* in one of my current 
projects where I adopted enums quite heavily. My suggestion was only that such 
a construct *could* be massaged to also cover ternary and thus could be 
considered a single construct that solved two “problems”: changing ternary to 
stand out slightly more, and getting switch-as-expression at the same time.

l8r
Sean

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

[David Hart via swift-evolution]

Sorry about the double post.

> On 05 Jan 2016, at 18:26, David Hart via swift-users  
> wrote:
> 
> How is it that Swift allows code like this:
> 
> struct Sneaky: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> }
> 
> func ~=(sneaky: Sneaky, string: String) -> Bool {
>   return false
> }
> 
> enum NormalEnum: String {
>   case Super = "super"
>   case Mario = "mario"
> }
> 
> let value = NormalEnum(rawValue: "super”) // return nil
> 
> It hit completely by surprise today because of of a Regex library:
> 
> struct Regex: StringLiteralConvertible {
>   init(stringLiteral value: String) {}
>   init(extendedGraphemeClusterLiteral value: String) {}
>   init(unicodeScalarLiteral value: String) {}
> 
>   //...
> }
> 
> func ~=(regex: Regex, string: String) -> Bool {
>   return regex.matches(string)
> }
> 
> If I was not already a Swift enthusiast, this behaviour would have left me 
> completely dumbfounded.
> What can we do about it?
> 
> David.
> 
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Dennis Lysenko via swift-evolution]

Everyone,

The sticking point here is that xcode generates the first syntax
automatically.

Simply filing a radar about this would be useless, so I believe the
original proposal is meant to sort-of "light a fire" under the Xcode team;
by introducing a new language feature they would be forced to support it.

Personally, I think it should just be fixed in Xcode as well, but it's not
that simple.

On Tue, Jan 5, 2016, 8:35 AM Jérôme Duquennoy 
wrote:

> Hi everybody,
>
> I do agree with Kevin : trailing closures is only a possibility offered by
> the language, you are not forced to use it.
> In the case you show, I agree that the second syntax is more readable than
> the first one. Good news is : it does compile :-).
>
> I think adding a specific keyword or annotation to locally forbid trailing
> closure would add complexity to the language for no real advantage.
>
> -1 for me thus.
>
> Jerome
>
>
>
> On 04 Jan 2016, at 19:52, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What's the point of this? What problem does it solve? If you don't want a
> trailing closure, just don't use trailing closure syntax. I don't see what
> benefit there is in explicitly annotating the function to disallow trailing
> closure syntax with it; just because you don't want to use trailing closure
> syntax doesn't mean nobody should be able to use it. And other people using
> it shouldn't affect you.
>
> -Kevin Ballard
>
> On Mon, Jan 4, 2016, at 04:45 AM, QQ Mail via swift-evolution wrote:
>
> Hi, All:
> trailing closure is good for most cases, but sometimes it is also make
> code unclear, for example:
>
> UIView.animateWithDuration(0.3, animations: { () -> Void in
> // animation code here
> }) { (Bool) -> Void in
> // completion code here
> }
>
> the label been removed and the code also not aligned well.
> I would like to write like this:
>
> UIView.animateWithDuration(0.3,
>
> animations: { () -> Void in
> // animation code here
> },
> completion: { Bool -> Void in
> // completion code here
> }
> )
>
> It is possible, just every time you have to write it manually. It’s a
> little wast.
> So I have a thought, since we already know this function is not well suit
> for trailing
> closure, can we add a attribute to disable it, for example:
>
> extensionUIView {
>
> @disable_trailing_closure
> public static func animateWithDuration(duration:NSTimeInterval,
> animations:()->Void, completion:()->Void) {
> // implementations ...
> }
> }
>
> I also found another one have issue for this too. link:
> http://www.natashatherobot.com/swift-trailing-closure-syntax/
> what do you think?
>
> Best Regards
>
> ChenYungui
>
> *___*
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 10:23 AM, Sean Heber  wrote:
> 
> 
>> 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: 0xFF
> 
> This is my favorite and addresses the sort of situations I’ve run into where 
> using a switch statement seems unnecessarily bulky. I’d like to see this as a 
> proposal because it’d be a very useful construct on its own.
> 
> Using “else” would be maybe a little odd when paired with cases, but it also 
> doesn’t look bad and, I think, could be argued that it makes sense in the 
> context of an expression:
> 
> let x = color ?
>  case .Red: 0xFF
>  case .Green: 0x00FF00
>  case .Blue: 0xFF
>  else: 0xFF
> 
> Then you could say this when using a boolean:
> 
> let x = something ? case true: thing() else: otherThing()
> 
> 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 pretty terse and 
> the addition of “else” in there makes the entire expression stand out a bit 
> more than traditional ternary expressions which, I think, addresses one of 
> the complaints there.

I do not like this idea.  I think a case expression should follow the case 
statement where a corresponding keyword is used.  If you want to make this more 
like ternary we should just allow `:` without any keyword for the default 
clause.

Your suggestion that this would replace ternary and require an `else:` instead 
of `:` is going to be a non-starter.  You may want to read the “frequently 
proposed changes” document as it explains why such a change won’t happen.

> 
> l8r
> Sean
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Félix Cloutier via swift-evolution]

Extensions on classes already work and I can't see them requiring @objc or 
@nonobjc. It's extensions on protocols that don't work from Objective-C. The 
way I understand it, Doug suggests a warning/error for extensions on @objc 
protocols, and a @nonobjc attribute to shut it up.

Your point may still stand if you use @objc protocols in your code.

Félix

> Le 5 janv. 2016 à 06:51:27, Andrey Tarantsov via swift-evolution 
>  a écrit :
> 
> I'm against this, because I often write extensions on Apple classes (like, 
> say, UIColor) that are only intended to be used from Swift, in a pure-Swift 
> project, and I need no stinking' @nonobjc in there.
> 
> How much of a problem can this surprise be? You call a method, the compiler 
> tells you it's not there, you look up the reason, no harm done.
> 
> A.
> 
> 
> 
>> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for newtype feature/typesafe calculations

[Thorsten Seitz via swift-evolution]

> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via swift-evolution 
> :
> 
> The ideal would be for the compiler to pretend Euros or RefTablePk are 
> different types, yet use their parent type at the binary level. This needs a 
> specific syntax to teach the compiler which existing methods/operations are 
> allowed on the new fake types and which aren’t. These new distinct types 
> would *borrow* previous implementations.

What about citing the relevant protocols in the newtype definition? This should 
include the ability to use my own protocols to which I have made the underlying 
type conform to by an extension.

Throwing some syntax into the discussion:

newtype Euro = Double : Addable, Subtractable

where I have defined the protocols Addable and Subtractable somewhere and made 
Double conform to them if all this is not provided by the standard library.
The implementation of Euro then borrows the implementation of Double for these 
protocols.

-Thorsten 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Failable Initializer Suggestion

[Dennis Lysenko via swift-evolution]

My initial stance several months ago was that initializers should throw
instead of returning nil, but I've changed it as a result of the error
handling rationale (same document as Chris linked).

Specifically this section, taken from ErrorHandlingRationale.rst:

Simple domain errors

A simple domain error is something like calling String.toInt() on a string
that isn't an integer. The operation has an obvious precondition about its
arguments, but it's useful to be able to pass other values to test whether
they're okay. The client will often handle the error immediately.

Conditions like this are best modeled with an optional return value. They
don't benefit from a more complex error-handling model, and using one would
make common code unnecessarily awkward. For example, speculatively trying
to parse aString as an integer in Java requires catching an exception,
which is far more syntactically heavyweight (and inefficient without
optimization).

Because Swift already has good support for optionals, these conditions do
not need to be a focus of this proposal.

In constructors, the most common (and I would posit the only common) case
of error would be a simple domain error, so failable initializers suffice.

On Tue, Jan 5, 2016 at 12:52 AM Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for keeping failable initializers. Error handling should be reserved
> for errors and not be used for control flow or logic.
>
> -Thorsten
>
> Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
>
> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I just found that the design of failable initializer is redundant in Swift
> 2. Because native error handling already has been introduced in Swift 2,
> and failable initializer indeed could be achieved by following codes:
>
>
> I’d be opposed to removing failable initializers.  Failable inits
> introduce a symmetry into the language for initializers, which make them
> possible to do (almost) all of what you can do with a normal method.  This
> capability is key for them to be able to replace “factory” static methods,
> which allows Swift to offer a consistent initialization pattern for clients
> of types.
>
> If we forced people to use error handling for anything that could return
> nil, then things like String to Int conversions would most likely not use
> initialization syntax.
>
> Besides that, over use of error handling waters it down and makes it less
> valuable in itself.  For more information on this, please see the design
> discussion for error handling:
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

[Paul Cantrell via swift-evolution]

> On Jan 4, 2016, at 5:39 PM, Kevin Ballard  wrote:
> 
> On Mon, Jan 4, 2016, at 03:22 PM, Paul Cantrell wrote:
>>  
>> The bottom line is that not every NSString → String bridge need to be O(n). 
>> At least in theory. Someone with more intimate knowledge of NSString can 
>> correct me if I’m wrong.
>  
> I thought it was a given that we can't modify NSString. If we can modify it, 
> all bets are off; heck, if we can modify it, why not just make NSString 
> reject invalid sequences to begin with?

Good question. And if we can’t modify NSString, then yes, we’re up against a 
tough problem.

But should NSString legacy constraints really compromise the design of Swift’s 
native String type?

Félix and Dmitri’s comments suggest that there are ways to prevent that, and 
that there’s precedent for placing any distasteful behavior necessary for 
compatibility in the bridging, not in the core type.

>> Keep in mind that we’re already incurring that O(n) expense right now for 
>> every Swift operation that turns an NSString-backed string into characters — 
>> that plus the API burden of having that check deferred, which is what 
>> originally motivated this thread.
>  
> That's true for native Strings as well. The native String storage is actually 
> a sequence of UTF-16 code units, it's not a sequence of characters. Any time 
> you iterate over the CharacterView, it has to calculate the grapheme cluster 
> boundaries.

Aren’t Swift strings encoded as UTF-8, —or at least designed to behave as if 
they are, however they might be stored under the hood?

https://github.com/apple/swift/blob/master/docs/StringDesign.rst#strings-are-encoded-as-utf-8
 

https://github.com/apple/swift/blob/master/docs/StringDesign.rst#how-would-you-design-it
 


Given the warning at the top about this having been a planning document, I see 
that this may no longer be true. But at least the original design rationale 
strongly suggests that String’s failable initializers should fail when given 
invalid Unicode.

> But that's ok, because unless you call `count` on it, you're typically doing 
> an O(N) operation _anyway_. But there's plenty of things you can do with 
> strings that don't require iterating over the CharacterView.


Indeed, but per my earlier message, those things could all still be O(1) except 
in the case when you’re transcoding a string from something other than ASCII or 
UTF-8 — and those transcoding cases are O(n) already. That certainly seems like 
a better design for the core lib.

Really hoping a core team member can weigh in on this….

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 11:05 AM, Thorsten Seitz  wrote:
> 
>> 
>> Am 05.01.2016 um 17:29 schrieb Matthew Johnson :
>> 
>> 
>>> On Jan 5, 2016, at 10:23 AM, Sean Heber  wrote:
>>> 
>>> 
 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: 0xFF
>>> 
>>> This is my favorite and addresses the sort of situations I’ve run into 
>>> where using a switch statement seems unnecessarily bulky. I’d like to see 
>>> this as a proposal because it’d be a very useful construct on its own.
>>> 
>>> Using “else” would be maybe a little odd when paired with cases, but it 
>>> also doesn’t look bad and, I think, could be argued that it makes sense in 
>>> the context of an expression:
>>> 
>>> let x = color ?
>>> case .Red: 0xFF
>>> case .Green: 0x00FF00
>>> case .Blue: 0xFF
>>> else: 0xFF
>>> 
>>> Then you could say this when using a boolean:
>>> 
>>> let x = something ? case true: thing() else: otherThing()
>>> 
>>> 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 pretty 
>>> terse and the addition of “else” in there makes the entire expression stand 
>>> out a bit more than traditional ternary expressions which, I think, 
>>> addresses one of the complaints there.
>> 
>> I do not like this idea.  I think a case expression should follow the case 
>> statement where a corresponding keyword is used.  
> 
> That's what I am thinking as well. Keep the similarities with the 
> corresponding statement as much as possible otherwise the result will be 
> confusing.
> 
>> If you want to make this more like ternary we should just allow `:` without 
>> any keyword for the default clause.
> 
> No, please. As I just said, keep the similarities with the corresponding 
> statement as close as possible.

I have no strong preference here. :)  I was just showing something that would 
increase similarity to ternary and make the case expression more concise if 
that was desired.

Is anybody going to write up a proposal for the ternary-like switch expression?

> 
>> Your suggestion that this would replace ternary and require an `else:` 
>> instead of `:` is going to be a non-starter. You may want to read the 
>> “frequently proposed changes” document as it explains why such a change 
>> won’t happen.
> 
> I'd prefe to keep the ternary as most compact form of a conditional instead 
> of watering down the switch-expression. Too confusing IMO.
> 
> 
> -Thorsten 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> Am 05.01.2016 um 16:23 schrieb Matthew Johnson 
> 
>> On Jan 5, 2016, at 9:12 AM, Craig Cruden  wrote:
>> 
>> Is there a reason why we are reusing “?” since the proposal is to leave 
>> ternary ? :  as is.  And “?” is also used by optionals.  Why not just use a 
>> new keyword like “match” (which I prefer better than which - but that may be 
>> because it is familiar to me :p ).  then reuse the rest of switch (i.e. 
>> case/default) syntax with expressions:
> 
> IMO visual similarity between both conditional expressions is an advantage 
> and the ? makes it stand out much more than your version with 'match'.

Yes, that's the idea. 

Using another keyword would make me wonder why there are two keywords for 
something similar with the only difference that one is an expression and the 
other a statement. That difference alone does not merit a different keyword, 
especially as there are so many languages that do not even make a distinction 
between those two cases and simply have only conditional expressions which can 
be used in statement position as well.

Reusing the ? resembles the ternary if-expression and therefore has some 
precedence and symmetry which would allow recognition and avoid confusion.

-Thorsten 

P.S. Actually I think it was someone else than me (sorry, don't know who) who 
first suggested this form for the switch-expression and I just reintroduced it 
sometime later back into the discussion as it seemed to have been overlooked. 

> 
>> 
>> i.e. 
>> let x = color match
>>  case .Red: 0xFF
>>  case .Red: 0x00FF00
>>  case .Red: 0xFF
>>  default: 0xFF
>> 
>> 
 On 2016-01-05, at 22:01:00, Matthew Johnson via swift-evolution 
  wrote:
 
 
 On Jan 5, 2016, at 12:29 AM, Thorsten Seitz  wrote:
 
 I once suggested the following ternary like switch:
 
 let x = color ?
 case .Red: 0xFF
case .Green: 0x00FF00
 case .Blue: 0xFF 
 default: 0xFF
>>> 
>>> This is the ternary-like switch I was referring to.  I think this is the 
>>> best case we can hope for given the comments in the “frequently proposed 
>>> changes” list.  A switch expression of some kind would be a nice 
>>> improvement and this fits well with the feasibility assumptions we should 
>>> make given those comments.
>>> 
 
 Reusing "case" and "default" makes it possible IMO to distinguish the 
 cases even if writing them in one line (which I would never do for a 
 switch-expression for readability). Furthermore it males it similar to the 
 switch statement and therefore recognizable.
 Last not least it keeps parsing for the compiler simple.
 
 The cases only allow expressions (I personally would allow blocks with the 
 last expression being the result of the block but there seems to be an 
 aversion to braces in expressions, so I could live with that restriction).
>>> 
>>> You could still use the immediately invoked closure trick here.  It’s not 
>>> that bad.
>>> 
 The patterns would allow everything that is allowed for patterns in switch 
 statements.
 
 -Thorsten 
 
> Am 05.01.2016 um 01:14 schrieb Matthew Johnson via swift-evolution 
> :
> 
> 
> 
> Sent from my iPad
> 
>> On Jan 4, 2016, at 5:45 PM, Charles Constant  
>> wrote:
>> 
>> Our ternary-like switch is now in the "commonly_proposed.md" file, which 
>> doesn't bode very well. It puzzles me that there isn't more enthusiasm. 
>> Are we the only ones who get irritated taking up so much space with a 
>> "switch" when all we need to do is transform between two sets of values?
> 
> The ternary-like switch expression is not on the list.  Changing or 
> removing ternary itself as well as turning if / else and switch into 
> expressions are on the list.
> 
> I think some potential issues with ternary-like switch may have come up 
> but maybe they can be resolved.  If not, I don't think we will see 
> progress in this area in the near future.
> 
>> 
>> I think we need to revamp the proposal somehow to make the idea clearer, 
>> because it ought to be pretty compelling.
>> 
>> • Does anyone here have better "side by side" examples of code 
>> before/after? 
>> 
>> • Can anyone think of a way to revise the (English) language of the 
>> proposal to make it shorter and sweeter? 
>> 
>> Apologies for prescribing instead of doing. My only excuse is that I'm 
>> "too busy"
>> 
>> 
>> 
>> 
>>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
 On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
 

Re: [swift-evolution] Support for newtype feature/typesafe calculations

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via swift-evolution 
>> :
>> 
>> The ideal would be for the compiler to pretend Euros or RefTablePk are 
>> different types, yet use their parent type at the binary level. This needs a 
>> specific syntax to teach the compiler which existing methods/operations are 
>> allowed on the new fake types and which aren’t. These new distinct types 
>> would *borrow* previous implementations.
> 
> What about citing the relevant protocols in the newtype definition? This 
> should include the ability to use my own protocols to which I have made the 
> underlying type conform to by an extension.

This is how my forwarding proposal works.  The newtype syntax I suggested as a 
possible extension looks like this:

newtype Euro = Double forwarding Addable, Subtractable

The keyword could be different, but I think `forwarding` is not bad.  When I 
complete the second draft I think it will make even more sense.  The forwarding 
facility has features to handle non-trivial cases (Self and associated type 
requirements, etc).

> 
> Throwing some syntax into the discussion:
> 
> newtype Euro = Double : Addable, Subtractable
> 
> where I have defined the protocols Addable and Subtractable somewhere and 
> made Double conform to them if all this is not provided by the standard 
> library.
> The implementation of Euro then borrows the implementation of Double for 
> these protocols.
> 
> -Thorsten 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

While it is real nice what can be done with a library solution, the 
switch-expression allows more than just comparing with a value. Library 
solutions won't be able to achieve the following features:

- pattern matching
- where clauses
- exhaustiveness check

-Thorsten 

> Am 05.01.2016 um 18:10 schrieb Jo Albright via swift-evolution 
> :
> 
> I am really enjoying this conversation. I think the ternary switch is useful 
> for advanced one line case values. I have been playing to see what can 
> currently be done. Attached is a playground for those who want to see 
> results… the range case takes a second to run. I know there can be 
> optimizations done, but just wanted to add my thoughts to the conversation. 
> 
> Chose ??? to denote a ternary switch, to be inline with ? = ternary, ?? = nil 
> coalescing … the other two operators where just placeholders. I don’t believe 
> || is a great solution as it is a comparison operator and —> is confusing and 
> resembles return… but again, nothing serious... just playing with playground 
> (indulging my current obsession with custom operators).
> 
> With the below, I don’t feel there is a huge need to change the language… 
> unless incorporating the actual switch optimization is worth it.
> 
> Thanks,
> Jo Albright
> 
> 
> // ??? loops array and returns first element where lhs == element.0
> infix operator ??? { associativity left precedence 200 }
> 
> // || merges values into an array
> infix operator || { associativity left precedence 210 }
> 
> // --> convert lhs & rhs to tuple (lhs,rhs)
> infix operator --> { associativity left precedence 220 }
> 
> func ??? (lhs: T?, rhs: [(T,AnyObject)]) -> AnyObject? {
> 
> for r in rhs { if lhs == r.0 { return r.1 } }; return nil
> 
> }
> 
> func ??? (lhs: T, rhs: [(T,AnyObject)]) -> AnyObject? {
> 
> for r in rhs { if lhs == r.0 { return r.1 } }; return nil
> 
> }
> 
> func || (lhs: (T,AnyObject), rhs: (T,AnyObject)) -> [(T,AnyObject)] {
> 
> return [lhs,rhs]
> 
> }
> 
> func || (lhs: [(T,AnyObject)], rhs: (T,AnyObject)) -> [(T,AnyObject)] {
> 
> return lhs + [rhs]
> 
> }
> 
> func || (lhs: (Range,AnyObject), rhs: (Range,AnyObject)) -> 
> [(T,AnyObject)] {
> 
> return lhs.0.map { ($0,lhs.1) } + rhs.0.map { ($0,rhs.1) }
> 
> }
> 
> func || (lhs: (Range,AnyObject), rhs: (T,AnyObject)) -> [(T,AnyObject)] 
> {
> 
> return lhs.0.map { ($0,lhs.1) } + [rhs]
> 
> }
> 
> func || (lhs: [(T,AnyObject)], rhs: (Range,AnyObject)) -> 
> [(T,AnyObject)] {
> 
> return lhs + rhs.0.map { ($0,rhs.1) }
> 
> }
> 
> func --> (lhs: T, rhs: AnyObject) -> (T,AnyObject) {
> 
> return (lhs,rhs)
> 
> }
> 
> 
> enum LifeStatus { case Alive, Dead, Zombie }
> 
> let life: LifeStatus? = .Dead
> 
> // embedded ternary operators … how I have built a ternary switch in past
> let color1 = life == .Alive ? UIColor.greenColor() : life == .Dead ? 
> UIColor.redColor() : life == .Zombie ? UIColor.grayColor() : 
> UIColor.whiteColor()
> 
> // using custom operators
> let color2 = life ??? .Alive --> UIColor.greenColor() || .Dead --> 
> UIColor.redColor() || .Zombie --> UIColor.grayColor() ?? UIColor.whiteColor()
> 
> let age = 15
> 
> // works with ranges
> let ageGroup = age ??? (0...1) --> "baby" || (2...4) --> "toddler" || 
> (5...12) --> "kid" || (13...19) --> "teen" ?? "adult"
> 
> ageGroup // “teen”
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Thoughts on clarity of Double and Float type names?

[Alex Johnson via swift-evolution]

Hi all,

I'm curious how other members of the Swift community feel about the clarity
of the "Double" and "Float" type names. It seems incongruous that the
default type for integers is "Int", but the default type for floating point
numbers is not "Float".

What if the name "Float" were given to the intrinsic, 64-bit floating point
type? (And the existing "Float" and "Double" names were removed in favor of
"Float32" and "Float64"?)


*Discussion:*

I understand the origins of these names in single- and double-precision
IEEE floats. But this distinction feels like a holdover from C (and a
32-bit world), rather than a natural fit for Swift.

Here are some reasons to *keep Double and Float as they are* (numbered for
easy reference, but otherwise unordered):

   1. "Double" and "Float" are more natural for developers who are
   "familiar with C-like languages."
   2. A corollary: A 64-bit "Float" type could be confusing to those
   developers.
   3. Another corollary: Swift needs to interoperate with Objective C, and
   its "float" and "double" types.
   4. Renaming these types would open the door to bike-shedding every type
   name and keyword in the language.
   5. Changing the meaning of an existing type ("Float") would be a bit
   PITA for existing code (although an automated migration from "Float" to
   "Float32" and "Double" to "Float" should be possible).
   6. Renaming a fundamental type would take considerable effort.

Here are some reasons to *rename these types*:

   1. The default for a "float literal" in Swift is a 64-bit value. It
   would feel natural if that that value were of type "Float".
   2. There are size-specific names for 32-bit ("Float32") and 64-bit
   ("Float64") floating point types. For cases where a size-specific type is
   needed, a size-specific name like "Float32" probably makes the intention of
   the code more clear (compared to just "Float").
   3. Apple's Objective C APIs generally use aliased types like "CGFloat"
   rather than raw float or double types.
   4. There is precedent for "Float" types being 64-bit in other languages
   like Ruby, Python and Go (as long as the hardware supports it).
   5. What kind of a name for a type is "Double" anyways, amirite?

(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are
there any pros or cons that I've missed? Is the level of effort so large
that it makes this change impractical? Is it a colossal waste of human
effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Paul Cantrell via swift-evolution]

> I’d also like to hear more thoughts on Kevin’s proposal from a broader range 
> of people.

Derp, I mean Brent’s proposal.

My brain is utterly unable to keep people’s names straight. Is there a clinical 
name for it? Because whatever it is, I’ve got it baaad.

Brent and Kevin, apologies!

P
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for newtype feature/typesafe calculations

[Matthew Johnson via swift-evolution]

Thanks for doing the work to collect links related to this topic!  I am 
planning to give them a read.

You may be interested in the proposal I am working on for automatic protocol 
forwarding.  

The first draft was posted to the list last week: 
https://github.com/anandabits/swift-evolution/blob/automatic-protocol-forwarding/proposals/-automatic-protocol-forwarding.md
 
.
  It will give you an idea of where the proposal is going, although it is 
somewhat out of date at this point.  The motivation section is also not fully 
fleshed out.  Several good suggestions came up during the discussion leading to 
some important design changes.

I am working on a significantly enhanced second draft right now.  It will 
include examples showing how it can be used to achieve a similar effect to 
`newtype` (as well as several other examples).  It won’t be quite as concise 
syntactically as it is designed to support many use cases, not just the 
`newtype` use case.  A future enhancement to that proposal might allow more 
concise syntax to better support the `newtype` use case.

I am hoping to have the second draft ready to share soon.  

Matthew

> On Jan 5, 2016, at 10:11 AM, Grzegorz Adam Hankiewicz via swift-evolution 
>  wrote:
> 
> Hello, newcomer here.
> 
> The other day I was reading about 
> https://www.reddit.com/r/swift/comments/3zbk64/type_math/ and given the 
> verbose solutions decided to pitch a possible language improvement. But after 
> reading through the archives it seems that this idea has already been pitched 
> before:
> 
> * Proposal: newtype feature for creating brand new types from existing types
> 
> - 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001821.html
> 
> - 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001826.html
> 
> Some time later:
> 
> * Epic: Typesafe calculations
> 
> - 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004735.html
> 
> Since this is already known I would like to talk about this potential feature 
> in order to address the perceived lack of community interest.
> 
> Recently I’ve been bitten by a lack of this feature for code dealing with 
> database serialisation. If a database table is modelled as an object it will 
> most likely use integers or longs to represent primary and foreign keys. An 
> example would be:
> 
> struct SomeTable {
>var primaryKey: Int64
>var otherTableForeignKey: Int64
>var yeatAnotherForeginKey: Int64
> }
> 
> Unfortunately the types can be mixed, one can assign the value from 
> otherTableForeignKey to primaryKey without impunity. Using the reddit 
> proposed struct as separate type would help here:
> 
>public struct RefTablePk {
>private let value: Int64
>}
> 
>public struct SomeTablePk {
>private let value: Int64
>}
> 
>struct RefTable {
>var primaryKey: RefTablePk
>}
> 
>struct SomeTable {
>var primaryKey = SomeTablePk(value: 0)
>var otherTableForeignKey = RefTablePk(value: 0)
>}
> 
>var a = SomeTable()
>a.primaryKey = SomeTablePk(value: 3)
>a.otherTableForeignKey = a.primaryKey // Fails, good!
>print(a.primaryKey.value)
> 
> So far so good. The solution gets more hairy when one attempts to use such 
> fake types for mathematical operations because the new type doesn’t inherit 
> possible operations done on the parent type it is based of:
> 
>public struct Euros {
>private let value: Double
>}
> 
>public struct Dollars {
>private let value: Double
>}
> 
>var account = Euros(value: 100)
>var bill = Euros(value: 42)
>account = account - bill
> 
> The last line won’t compile: Binary operator ‘-‘ cannot be applied to two 
> ‘Euros’ operands. The immediate solution would be to add variants of all the 
> usual operators for every type, which quickly gets tedious and verbose. On 
> top of this, each *new* type is generating code, which is actually not 
> desirable. The ideal would be for the compiler to pretend Euros or RefTablePk 
> are different types, yet use their parent type at the binary level. This 
> needs a specific syntax to teach the compiler which existing 
> methods/operations are allowed on the new fake types and which aren’t. These 
> new distinct types would *borrow* previous implementations.
> 
> Other examples of possible use for such fake types (note again: these exist 
> only at compilation time and generate no extra code) would be user input 
> validation. Strings coming from *the exterior* (whatever that might be) could 
> use a distinct type of TaintedString instead of the usual String, and would 
> require a validation or converter function to produce a correct String, or 
> maybe a ValidatedString for better distinction. Similarly for a 

[swift-evolution] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

[David Hart via swift-evolution]

How is it that Swift allows code like this:

struct Sneaky: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}
}

func ~=(sneaky: Sneaky, string: String) -> Bool {
return false
}

enum NormalEnum: String {
case Super = "super"
case Mario = "mario"
}

let value = NormalEnum(rawValue: "super”) // return nil

It hit completely by surprise today because of of a Regex library:

struct Regex: StringLiteralConvertible {
init(stringLiteral value: String) {}
init(extendedGraphemeClusterLiteral value: String) {}
init(unicodeScalarLiteral value: String) {}

//...
}

func ~=(regex: Regex, string: String) -> Bool {
return regex.matches(string)
}

If I was not already a Swift enthusiast, this behaviour would have left me 
completely dumbfounded.
What can we do about it?

David.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default lazy constructor

[Félix Cloutier via swift-evolution]

Have you heard of the property behaviors proposal?

Félix

> Le 5 janv. 2016 à 08:48:03, James Campbell via swift-evolution 
>  a écrit :
> 
> When creating a lazy variable, maybe we should allow for default closures, i.e
> 
> lazy var userSession: UserSession
> 
> Which will construct that object for you
> instead of having to do:
> 
> lazy var object: MyObject {
> let userSession = UserSession()
> 
> return userSession
> 
> }()
> 
> If the initializer requires parameter values then as an extension of this we 
> could pass them in psuedo C++ style:
> 
> lazy var object: UserSession(otherVariable) 
> 
> Potentially otherVariable in this case could be lazily processed, so that its 
> the equivalent of:
> 
> 
> lazy var object: MyObject {
> let userSession = UserSession(otherVariable)
> 
> return userSession
> 
> }()
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 5, 2016, at 3:51 AM, Andrey Tarantsov  wrote:
> 
> I'm against this, because I often write extensions on Apple classes (like, 
> say, UIColor) that are only intended to be used from Swift, in a pure-Swift 
> project, and I need no stinking' @nonobjc in there.

You are misreading my proposal. I’m not proposing to change anything about how 
extensions of classes work. Your extensions of UIColor and other Objective-C 
classes remain unchanged.

How many Apple *protocols*, such as delegates, have you extended? I expect it’s 
not that many.

> 
> How much of a problem can this surprise be? You call a method, the compiler 
> tells you it's not there, you look up the reason, no harm done.

I’ve seen enough bugs filed and general confusion about this that the answer is 
“it’s quite a bit of a surprise”. The common case seems to be that people write 
a protocol extension of a delegate that implements some of its optional 
members. The only calls to that method occur in some framework code written in 
Objective-C, so there place for the compiler to tell you it’s not there.

- Doug

> 
> A.
> 
> 
> 
>> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Customized Inline Init Closure

[Thorsten Seitz via swift-evolution]

Very nice! 
I also think that using $0 is fine as it avoids all the problems with shadowing 
the outer self and thereby avoids erros and increases readability.

-Thorsten 

> Am 04.01.2016 um 18:51 schrieb Jo Albright via swift-evolution 
> :
> 
> Here is another option. Attached is a playground I was messing around with. 
> There are some weird bugs I was noticing, but don’t quite know if they are 
> important enough to submit (comment out line 54 to see).
> 
> I actually like using the $0 so as to allow access to self if using within 
> another type (ex: view controller code below).
> 
> Please respond with any potential issues with the code I have written.
> 
> - Jo
> 
> 
> 
> protocol ClosureInit { init() }
> 
> extension ClosureInit {
> 
> init(@noescape b: inout Self -> Void) { self.init(); b() }
> 
> }
> 
> struct Person: ClosureInit {
> 
> enum GenderType: String { case Male, Female }
> 
> var age: Int = 0
> var gender: GenderType?
> var name: String?
> 
> }
> 
> let me = Person {
> 
> $0.name = "Jo"
> $0.age = 32
> $0.gender = .Male
> 
> }
> 
> me.age // 32
> 
> extension Array: ClosureInit { }
> 
> let randomIntArray = [Int] {
> 
> for _ in 0...10 {
> 
> $0.append(Int(arc4random_uniform(100)))
> 
> }
> 
> }
> 
> randomIntArray
> 
> let personArray = [Person] {
> 
> for _ in 0...8 {
> 
> $0.append(Person {
> 
> $0.age = Int(arc4random_uniform(100))
> $0.gender = Int(arc4random_uniform(100)) % 2 == 0 ? .Male : 
> .Female // comment this line out to see error
> 
> 
> })
> 
> }
> 
> }
> 
> personArray
> 
> extension UIView: ClosureInit { }
> 
> class ViewController: UIViewController {
> 
> override func viewDidLoad() {
> super.viewDidLoad()
> 
> UILabel {
> 
> $0.text = "This is Awesome!"
> $0.textColor = UIColor.cyanColor()
> $0.frame = CGRect(x: 20, y: 20, width: view.frame.width - 40, 
> height: 40)
> view.addSubview($0)
> 
> }
> 
> view.addSubview(UIButton {
> 
> $0.setTitle("Submit", forState: .Normal)
> $0.frame = CGRect(x: 20, y: 60, width: view.frame.width - 40, 
> height: 40)
> 
> })
> 
> 
> }
> 
> }
> 
> let vc = ViewController()
> 
> vc.loadViewIfNeeded()
> 
> vc.view.subviews
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Charles Srstka via swift-evolution]

> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> There is no direct way to implement Objective-C entry points for protocol 
> extensions. One would effectively have to install a category on every 
> Objective-C root class [*] with the default implementation or somehow 
> intercept all of the operations that might involve that selector. 

I can almost do it right now, just hacking with the Objective-C runtime 
functions, so I’d think that if you were actually working with the compiler 
sources, it should be doable. The trouble is on the Swift side; currently there 
aren’t any reflection features that I can find that work on Swift protocols.

If I have a protocol and class, like so:

import Foundation

@objc protocol HasSwiftExtension {}

@objc protocol P: HasSwiftExtension {
optional func foo()
}

extension P {
func foo() { print("foo") }
}

class C: NSObject, P {}

(the optional is there because without it, adding the method in an extension 
causes the compiler to crash on my machine)

And then I have this in Objective-C:

@implementation NSObject (Swizzle)
+ (void)load {
CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent();

unsigned int classCount = 0;
Class *classes = objc_copyClassList();

Protocol *proto = @protocol(HasSwiftExtension);

for (unsigned int i = 0; i < classCount; i++) {
Class eachClass = classes[i];

if (class_conformsToProtocol(eachClass, proto)) {
unsigned int protoCount = 0;
Protocol * __unsafe_unretained *protocols = 
class_copyProtocolList(eachClass, );

for (unsigned int j = 0; j < protoCount; j++) {
Protocol *eachProto = protocols[j];

if (protocol_conformsToProtocol(eachProto, proto)) {
unsigned int methodCount = 0;
// what we would want would be to pass YES for 
isRequiredMethod; unfortunately,
// adding optional methods to an @objc protocol in an 
extension currently just
// crashes the compiler when I try it. So pass NO, for the 
demonstration.
struct objc_method_description *methods = 
protocol_copyMethodDescriptionList(eachProto, NO, YES, );

for (unsigned int k = 0; k < methodCount; k++) {
struct objc_method_description method = methods[k];

if (!class_respondsToSelector(eachClass, method.name)) {
[SwizzleWrapper swizzleClass:[eachClass class] 
protocol:eachProto method:method];
}
}

free(methods);
}
}

free(protocols);
}
}

free(classes);

NSLog(@"took %f seconds", CFAbsoluteTimeGetCurrent() - startTime);
}
@end

The swizzleClass:protocol:method: method will get called for each missing 
method, assuming I’ve marked the protocols having an extension by making them 
conform to my HasSwiftExtension protocol, which the compiler could add 
automatically. (For the record, the time taken was 0.001501 seconds in my 
testing, while linking against both Foundation and AppKit).

Unfortunately there’s currently no way to go any further, since AFAIK there’s 
no way to reflect on a protocol to get a mapping from selector name to method. 
For this to work, you’d have to store the method names for methods added by 
extensions to @objc protocols as strings somewhere, and then have a reflection 
API to access them. However, if you added that, you could just:

class SwizzleWrapper: NSObject {
class func swizzleClass(aClass: AnyClass, `protocol` aProto: Protocol, 
method: objc_method_description) {
let imp: IMP

// now, just add some reflection for protocols to the language so we can
// figure out what method to call and set imp accordingly, and:

class_addMethod(aClass, method.name, imp, method.types) // ta da!
}
}

The other obvious disclaimer, of course, is that +load is probably not the 
right place to do this; you’d need to set things up such that they would run 
sometime after the Swift runtime has had a chance to finish initializing; the 
code as above probably isn’t safe if the Swift method being called actually 
does anything. But with access to the compiler source, you could make sure to 
get the SetUpStuff() method to run at the appropriate time, so that it could 
call into Swift and do its setup.

(For the record, I’m not advocating actually using the swizzling method 
described above; just pointing out that intercepting the selector is possible. 
Working with the compiler sources, I’d expect more elegant solutions would be 
possible.)

Charles

___
swift-evolution 

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

[Matthew Johnson via swift-evolution]

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

This is the ternary-like switch I was referring to.  I think this is the best 
case we can hope for given the comments in the “frequently proposed changes” 
list.  A switch expression of some kind would be a nice improvement and this 
fits well with the feasibility assumptions we should make given those comments.

> 
> Reusing "case" and "default" makes it possible IMO to distinguish the cases 
> even if writing them in one line (which I would never do for a 
> switch-expression for readability). Furthermore it males it similar to the 
> switch statement and therefore recognizable.
> Last not least it keeps parsing for the compiler simple.
> 
> The cases only allow expressions (I personally would allow blocks with the 
> last expression being the result of the block but there seems to be an 
> aversion to braces in expressions, so I could live with that restriction).

You could still use the immediately invoked closure trick here.  It’s not that 
bad.

> The patterns would allow everything that is allowed for patterns in switch 
> statements.
> 
> -Thorsten 
> 
> Am 05.01.2016 um 01:14 schrieb Matthew Johnson via swift-evolution 
> >:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Jan 4, 2016, at 5:45 PM, Charles Constant > > wrote:
>> 
>>> Our ternary-like switch is now in the "commonly_proposed.md 
>>> " file, which doesn't bode very well. It 
>>> puzzles me that there isn't more enthusiasm. Are we the only ones who get 
>>> irritated taking up so much space with a "switch" when all we need to do is 
>>> transform between two sets of values?
>> 
>> The ternary-like switch expression is not on the list.  Changing or removing 
>> ternary itself as well as turning if / else and switch into expressions are 
>> on the list.
>> 
>> I think some potential issues with ternary-like switch may have come up but 
>> maybe they can be resolved.  If not, I don't think we will see progress in 
>> this area in the near future.
>> 
>>> 
>>> I think we need to revamp the proposal somehow to make the idea clearer, 
>>> because it ought to be pretty compelling.
>>> 
>>> • Does anyone here have better "side by side" examples of code 
>>> before/after? 
>>> 
>>> • Can anyone think of a way to revise the (English) language of the 
>>> proposal to make it shorter and sweeter? 
>>> 
>>> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
>>> busy"
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
 > wrote:
 
 Good feedback, I am all for making it feel more like swift. Any ideas 
 would be welcome. I will also try to come up with some myself. 
>>> 
>>> My suggestion is to leave ternary alone and try to come up with a 
>>> ternary-like switch expression that is workable.  I think that is likely 
>>> the best change possible at this point.
>>> 
 
 
> On Jan 4, 2016, at 12:34 PM, Rod Brown  > wrote:
> 
> For all the proposals I've seen on this topic, I have to say -1.
> 
> While I agree with the notions surrounding this operator, I've yet to see 
> a better alternative presented, and none that feel truly Swift.
> 
> If someone has a great proposal, though, I look forward to seeing it.
> 
> - Rod
> 
> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
> > wrote:
> 
>> -1 for me. None of it looks or feels like Swift, more like Haskell. I 
>> would prefer a library solution for now and remove ?: from the language 
>> and add a which into the standard library and see how that goes and if 
>> there is need for more.
>> 
>> Sorry,
>> 
>> Howard.
>> 
>>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>> > wrote:
>>> 
>>> Any feedback on this? I am rethinking the idea of #( because of the # 
>>> prior usage as a preprocessor directive, but like how it stands out and 
>>> has a meaning.  If no feedback, does it make sense to update my 
>>> proposal with these ideas? Or does this feel like the wrong direction. 
>>> 
>>> 
 On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen 

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 11:31 PM, Howard Lovatt  wrote:
> 
> I was guessing that the current proposal does not change anything re. default 
> and current member wise initializers and so in addition to suggesting Scala 
> syntax I was also suggesting the transformation shown, or its equivalent. The 
> advantage of having a member wise init that has default arguments and 
> argument labels are considerable:
> 
> 1. Allows lets as well as vars 

The proposal does allow lets as well as vars.  It is very unfortunate that 
defaults for lets cannot be supported immediately.  Doing that is a highly 
desired enhancement.  If you read Chris Lattner’s comments in the history of 
this thread you will have more background on the issues involved.

> 2. Allows partial custom initialization 

I don’t know for sure what you mean by this but the proposal does allow partial 
custom initialization in the way I think of that phrase.

> 3. Eliminates need for other mechanisms, i.e. default and existing member 
> wise initialization  
> 
> These facilities could be added to `memberwise init(...)` as well. In 
> particular, if a member wise init was present then an initialized property 
> could have a label, e.g.:

I do not think allowing custom labels for memberwise initialization parameters 
is a good idea.  The caller is initializing a member directly.  It is more 
clear if the name of the parameter matches the name of the parameter.

> 
>  class C {
>  let example name: Type = initial
>  memberwise init(...)
>  }
> 
> Would become the equivalent of:
> 
>  class C {
>  let name: Type
>  init(example name: Type = initial) {
>  self.name  = name
>  }
>   }
> 
> The Scala syntax is just a shorter alternative, ideally there be a discussion 
> of the pros and cons of the two syntax that included the possibility of the 
> wider set of objectives as outlined in the numbered points above.

It was not a goal of this proposal to provide the most concise syntax for 
simple cases.  The goal of this proposal is to provide a flexible and scalable 
memberwise initialization facility.  Specific goals included supporting more 
than one memberwise initializer as well as allowing some properties to be 
memberwise initialized and some (private state, etc) to be initialized by other 
means.

An independent proposal focused on making simple cases as concise as possible 
is something that could also be pursued.

> 
> On Tuesday, 5 January 2016, Matthew Johnson  > wrote:
> 
>> On Jan 4, 2016, at 5:48 PM, Howard Lovatt > > wrote:
>> 
>> Yes you can get close, but:
>> 
>> 1. Its weird that you can only do this in an extension.
> 
> This is the way the current implicit initializer works.  It is not 
> synthesized if you define any initializers in the body of the type.  There 
> are good reasons it works this way and the current proposal does not change 
> those rules.
> 
>> 2. Its not quite the same as the proposal the current member-wise 
>> initialiser does not make the init arguments optional (the arguments 
>> themselves do not have defaults), i.e. with your example `let 
>> defaultOriginRect = Rect(size: Size(width: 5.0, height: 5.0))` fails whereas 
>> it would work for the proposal (this could also be true if the existing 
>> struct memberwise init and the new `memberwise init(..)` where changed to 
>> provide init argument defaults).
> 
> The implicit memberwise initializer currently in the language does not 
> provide defaults for parameters.  This proposal changes that behavior and 
> provides defaults if the the member is a `var` and has an initial value.  
> 
> Unfortunately I was not able to find a solution to allow synthesized 
> parameters for `let` members to have default values.  This is because the 
> current semantics for `let` members do not allow the member to be initialized 
> to anything other than the initial value if one is provided.  I am hoping a 
> solution to this will be identified in the future and have suggested one 
> possible mechanism `@default` in the future enhancements section.
> 
>> 3. Only ‘really' works for structs, the compiler doesn’t write a member-wise 
>> initialiser for classes (just a default initializer).
> 
> That is true about the current behavior of the language but is not true with 
> regards to the current proposal.
> 
>> 4. Still need the compiler to provide both default and member-wise 
>> initialisers, whereas this proposal would allow the existing default and 
>> member-wise initialisers to be deprecated and just the new member-wise 
>> initialiser would remain which would simplify the language and make it clear 
>> what was happening (this could also be true if a `memberwise init(..)` where 
>> added and existing compiler written inits removed).
> 

Re: [swift-evolution] Testing Assertions

[Jérôme Duquennoy via swift-evolution]

It is true that testing an assert is not really possible, as it basically 
crashes the app.

But we have to take into account that the behaviour of the assert method is not 
strait-forward : it depends on what is the optimisation level. Here is an 
extract of the inline doc of the assert method :

* In playgrounds and -Onone builds (the default for Xcode's Debug
  configuration): if `condition` evaluates to false, stop program
  execution in a debuggable state after printing `message`.
* In -O builds (the default for Xcode's Release configuration),
  `condition` is not evaluated, and there are no effects.
* In -Ounchecked builds, `condition` is not evaluated, but the
  optimizer may assume that it *would* evaluate to `true`. Failure
  to satisfy that assumption in -Ounchecked builds is a serious
  programming error.

I have the feeling that assertions are not meant to be tested, as they are not 
meant to be executed in production code.
And I have to add that writing tests that would not behave the same depending 
on the optimisation level would make me feel rather uncomfortable.

Maybe throwing an error would be more adapted for a validation that must also 
occur on production builds ?
Then, testing it would be pretty easy, with an extension to XCTestCase like 
that :

extension XCTestCase {

  func XCTAssertThrows(file: String = __FILE__, line: UInt = __LINE__, _ 
closure:() throws -> Void) {
do {
  try closure();
  XCTFail("Closure did not throw an error", file: file, line: line);
} catch {
  // expected, nothing to do
}
  }
  
  func XCTAssertNoThrow(file: String = __FILE__, line: UInt = __LINE__, _ 
closure:() throws -> T) -> T? {
do {
  return try closure();
} catch let error {
  XCTFail("Closure throw unexpected error \(error)", file: file, line: 
line);
}
return nil;
  }
  
}

Jérôme


> On 05 Jan 2016, at 01:42, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Mohamed,
> 
> I agree it’s very difficult to test assertions in XCTest today. This approach 
> looks interesting, but I’m not sure how it’s possible to implement within 
> XCTest’s current architecture. Do you have any idea how this would be 
> implemented? 
> 
> - Tony
> 
>> On Dec 31, 2015, at 1:35 AM, Mohamed Ebrahim Afifi via swift-evolution 
>> > wrote:
>> 
>> Right now, we cannot easily test failed assertions (assert, 
>> assertionFailure, precondition, preconditionFailure, fatalError) in our own 
>> code without some hacks in the code under test. Like this example 
>> https://github.com/mohamede1945/AssertionsTestingExample 
>> 
>> 
>> So, my suggestion is to add for XCTest something very similar to 
>> expectCrashLater that is defined here 
>> https://github.com/apple/swift/blob/9b15d03b73b9e8a6dbd3f71b5c78660a359e8e26/stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>>  
>> 
>> and used in tests like this example 
>> https://github.com/apple/swift/blob/master/validation-test/stdlib/Assert.swift
>>  
>> 
>> 
>> What do you think?
>> 
>> Best Regards,
>> Mohamed Afifi
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Default lazy constructor

[James Campbell via swift-evolution]

When creating a lazy variable, maybe we should allow for default closures,
i.e

lazy var userSession: UserSession

Which will construct that object for you
instead of having to do:

lazy var object: MyObject {

let userSession = UserSession()

return userSession

}()

If the initializer requires parameter values then as an extension of this
we could pass them in psuedo C++ style:

lazy var object: UserSession(otherVariable)

Potentially otherVariable in this case could be lazily processed, so that
its the equivalent of:

lazy var object: MyObject {

let userSession = UserSession(otherVariable)

return userSession

}()

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Craig Cruden via swift-evolution]

Is there a reason why we are reusing “?” since the proposal is to leave ternary 
? :  as is.  And “?” is also used by optionals.  Why not just use a new keyword 
like “match” (which I prefer better than which - but that may be because it is 
familiar to me :p ).  then reuse the rest of switch (i.e. case/default) syntax 
with expressions:

i.e. 
let x = color match
case .Red: 0xFF
case .Red: 0x00FF00
case .Red: 0xFF
default: 0xFF


> On 2016-01-05, at 22:01:00, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz > > wrote:
>> 
>> I once suggested the following ternary like switch:
>> 
>> let x = color ?
>> case .Red: 0xFF
>>  case .Green: 0x00FF00
>> case .Blue: 0xFF 
>> default: 0xFF
> 
> This is the ternary-like switch I was referring to.  I think this is the best 
> case we can hope for given the comments in the “frequently proposed changes” 
> list.  A switch expression of some kind would be a nice improvement and this 
> fits well with the feasibility assumptions we should make given those 
> comments.
> 
>> 
>> Reusing "case" and "default" makes it possible IMO to distinguish the cases 
>> even if writing them in one line (which I would never do for a 
>> switch-expression for readability). Furthermore it males it similar to the 
>> switch statement and therefore recognizable.
>> Last not least it keeps parsing for the compiler simple.
>> 
>> The cases only allow expressions (I personally would allow blocks with the 
>> last expression being the result of the block but there seems to be an 
>> aversion to braces in expressions, so I could live with that restriction).
> 
> You could still use the immediately invoked closure trick here.  It’s not 
> that bad.
> 
>> The patterns would allow everything that is allowed for patterns in switch 
>> statements.
>> 
>> -Thorsten 
>> 
>> Am 05.01.2016 um 01:14 schrieb Matthew Johnson via swift-evolution 
>> >:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Jan 4, 2016, at 5:45 PM, Charles Constant >> > wrote:
>>> 
 Our ternary-like switch is now in the "commonly_proposed.md 
 " file, which doesn't bode very well. It 
 puzzles me that there isn't more enthusiasm. Are we the only ones who get 
 irritated taking up so much space with a "switch" when all we need to do 
 is transform between two sets of values?
>>> 
>>> The ternary-like switch expression is not on the list.  Changing or 
>>> removing ternary itself as well as turning if / else and switch into 
>>> expressions are on the list.
>>> 
>>> I think some potential issues with ternary-like switch may have come up but 
>>> maybe they can be resolved.  If not, I don't think we will see progress in 
>>> this area in the near future.
>>> 
 
 I think we need to revamp the proposal somehow to make the idea clearer, 
 because it ought to be pretty compelling.
 
 • Does anyone here have better "side by side" examples of code 
 before/after? 
 
 • Can anyone think of a way to revise the (English) language of the 
 proposal to make it shorter and sweeter? 
 
 Apologies for prescribing instead of doing. My only excuse is that I'm 
 "too busy"
 
 
 
 
 On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
 > wrote:
 
> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
> > wrote:
> 
> Good feedback, I am all for making it feel more like swift. Any ideas 
> would be welcome. I will also try to come up with some myself. 
 
 My suggestion is to leave ternary alone and try to come up with a 
 ternary-like switch expression that is workable.  I think that is likely 
 the best change possible at this point.
 
> 
> 
>> On Jan 4, 2016, at 12:34 PM, Rod Brown > > wrote:
>> 
>> For all the proposals I've seen on this topic, I have to say -1.
>> 
>> While I agree with the notions surrounding this operator, I've yet to 
>> see a better alternative presented, and none that feel truly Swift.
>> 
>> If someone has a great proposal, though, I look forward to seeing it.
>> 
>> - Rod
>> 
>> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>> > wrote:
>> 
>>> -1 for me. None of it looks or feels like Swift, more like Haskell. I 
>>> would prefer a library solution for now and remove ?: from the 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 5, 2016, at 9:12 AM, Craig Cruden  wrote:
> 
> Is there a reason why we are reusing “?” since the proposal is to leave 
> ternary ? :  as is.  And “?” is also used by optionals.  Why not just use a 
> new keyword like “match” (which I prefer better than which - but that may be 
> because it is familiar to me :p ).  then reuse the rest of switch (i.e. 
> case/default) syntax with expressions:

IMO visual similarity between both conditional expressions is an advantage and 
the ? makes it stand out much more than your version with 'match'.

> 
> i.e. 
> let x = color match
>   case .Red: 0xFF
>   case .Red: 0x00FF00
>   case .Red: 0xFF
>   default: 0xFF
> 
> 
>>> On 2016-01-05, at 22:01:00, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz  wrote:
>>> 
>>> I once suggested the following ternary like switch:
>>> 
>>> let x = color ?
>>> case .Red: 0xFF
>>> case .Green: 0x00FF00
>>> case .Blue: 0xFF 
>>> default: 0xFF
>> 
>> This is the ternary-like switch I was referring to.  I think this is the 
>> best case we can hope for given the comments in the “frequently proposed 
>> changes” list.  A switch expression of some kind would be a nice improvement 
>> and this fits well with the feasibility assumptions we should make given 
>> those comments.
>> 
>>> 
>>> Reusing "case" and "default" makes it possible IMO to distinguish the cases 
>>> even if writing them in one line (which I would never do for a 
>>> switch-expression for readability). Furthermore it males it similar to the 
>>> switch statement and therefore recognizable.
>>> Last not least it keeps parsing for the compiler simple.
>>> 
>>> The cases only allow expressions (I personally would allow blocks with the 
>>> last expression being the result of the block but there seems to be an 
>>> aversion to braces in expressions, so I could live with that restriction).
>> 
>> You could still use the immediately invoked closure trick here.  It’s not 
>> that bad.
>> 
>>> The patterns would allow everything that is allowed for patterns in switch 
>>> statements.
>>> 
>>> -Thorsten 
>>> 
 Am 05.01.2016 um 01:14 schrieb Matthew Johnson via swift-evolution 
 :
 
 
 
 Sent from my iPad
 
> On Jan 4, 2016, at 5:45 PM, Charles Constant  
> wrote:
> 
> Our ternary-like switch is now in the "commonly_proposed.md" file, which 
> doesn't bode very well. It puzzles me that there isn't more enthusiasm. 
> Are we the only ones who get irritated taking up so much space with a 
> "switch" when all we need to do is transform between two sets of values?
 
 The ternary-like switch expression is not on the list.  Changing or 
 removing ternary itself as well as turning if / else and switch into 
 expressions are on the list.
 
 I think some potential issues with ternary-like switch may have come up 
 but maybe they can be resolved.  If not, I don't think we will see 
 progress in this area in the near future.
 
> 
> I think we need to revamp the proposal somehow to make the idea clearer, 
> because it ought to be pretty compelling.
> 
> • Does anyone here have better "side by side" examples of code 
> before/after? 
> 
> • Can anyone think of a way to revise the (English) language of the 
> proposal to make it shorter and sweeter? 
> 
> Apologies for prescribing instead of doing. My only excuse is that I'm 
> "too busy"
> 
> 
> 
> 
>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>>>  wrote:
>>> 
>>> Good feedback, I am all for making it feel more like swift. Any ideas 
>>> would be welcome. I will also try to come up with some myself. 
>> 
>> My suggestion is to leave ternary alone and try to come up with a 
>> ternary-like switch expression that is workable.  I think that is likely 
>> the best change possible at this point.
>> 
>>> 
>>> 
 On Jan 4, 2016, at 12:34 PM, Rod Brown  
 wrote:
 
 For all the proposals I've seen on this topic, I have to say -1.
 
 While I agree with the notions surrounding this operator, I've yet to 
 see a better alternative presented, and none that feel truly Swift.
 
 If someone has a great proposal, though, I look forward to seeing it.
 
 - Rod
 
> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> 

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[Alexander Kempgen via swift-evolution]

Yes. All of these variants are covered in the book The Swift Programming 
Language in some detail.

Alex

–
Alexander Kempgen
a...@kempgen.de

> Am 05.01.2016 um 14:42 schrieb James Campbell via swift-evolution 
> :
> 
> So the [Int]() is shorthand for Array()
> 
> On Tue, Jan 5, 2016 at 1:01 PM, Jeremy Pereira 
> > 
> wrote:
> 
> > On 5 Jan 2016, at 12:51, James Campbell  > > wrote:
> >
> > The problem for me is that is so counter intuitive I didn't even know you 
> > could do that.
> 
> The first one is a bit counter intuitive and I agree that
> 
> var distanceCache: [Int: Int] = []
> 
> might be an improvement, albeit not one I think many people would agree is 
> worth doing. However, the second one is a natural extrapolation from the 
> equivalent array syntax i.e.
> 
> var array = [Int]()
> var dictionary = [String: Int]()
> 
> >
> > On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira 
> > > 
> > wrote:
> > I don’t understand what the problem is
> >
> > > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution 
> > > > wrote:
> > >
> > > See this code:
> > > var distanceCache: [Int: Int] = Dictionary()
> > >
> > > It is very long and tedious to write especially if what I am storing 
> > > changes.
> > >
> > > I propose we be allowed to do the following:
> > > var distanceCache: [Int: Int] = []
> >
> > You can do
> >
> > var distanceCache: [Int: Int] = [:]
> >
> > Also
> >
> > var distanceCache2 = [Int: Int]()
> >
> >
> > > Perhaps this dictionary syntax is just confusing and it was a bad idea to 
> > > make it the same as an array. Most languages use "{" so why did swift 
> > > choose to share "[" with arrays and dictionaries.
> >
> > It’s not the same, you need the colons inside. I imagine that braces were 
> > discarded on the grounds that it would confuse the compiler with respect to 
> > closures, for example
> >
> > var myClosure = {} // is a variable of type () -> ()
> >
> >
> > >
> > > --
> > >  Wizard
> > > ja...@supmenow.com 
> > > +44 7523 279 698 
> > >  ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org 
> > > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > > 
> >
> >
> >
> >
> > --
> >  Wizard
> > ja...@supmenow.com 
> > +44 7523 279 698 
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

I once suggested the following ternary like switch:

let x = color ?
case .Red: 0xFF
case .Green: 0x00FF00
case .Blue: 0xFF 
default: 0xFF

Reusing "case" and "default" makes it possible IMO to distinguish the cases 
even if writing them in one line (which I would never do for a 
switch-expression for readability). Furthermore it males it similar to the 
switch statement and therefore recognizable.
Last not least it keeps parsing for the compiler simple.

The cases only allow expressions (I personally would allow blocks with the last 
expression being the result of the block but there seems to be an aversion to 
braces in expressions, so I could live with that restriction).
The patterns would allow everything that is allowed for patterns in switch 
statements.

-Thorsten 

> Am 05.01.2016 um 01:14 schrieb Matthew Johnson via swift-evolution 
> :
> 
> 
> 
> Sent from my iPad
> 
>> On Jan 4, 2016, at 5:45 PM, Charles Constant  wrote:
>> 
>> Our ternary-like switch is now in the "commonly_proposed.md" file, which 
>> doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are 
>> we the only ones who get irritated taking up so much space with a "switch" 
>> when all we need to do is transform between two sets of values?
> 
> The ternary-like switch expression is not on the list.  Changing or removing 
> ternary itself as well as turning if / else and switch into expressions are 
> on the list.
> 
> I think some potential issues with ternary-like switch may have come up but 
> maybe they can be resolved.  If not, I don't think we will see progress in 
> this area in the near future.
> 
>> 
>> I think we need to revamp the proposal somehow to make the idea clearer, 
>> because it ought to be pretty compelling.
>> 
>> • Does anyone here have better "side by side" examples of code before/after? 
>> 
>> • Can anyone think of a way to revise the (English) language of the proposal 
>> to make it shorter and sweeter? 
>> 
>> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
>> busy"
>> 
>> 
>> 
>> 
>>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
 On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
  wrote:
 
 Good feedback, I am all for making it feel more like swift. Any ideas 
 would be welcome. I will also try to come up with some myself. 
>>> 
>>> My suggestion is to leave ternary alone and try to come up with a 
>>> ternary-like switch expression that is workable.  I think that is likely 
>>> the best change possible at this point.
>>> 
 
 
> On Jan 4, 2016, at 12:34 PM, Rod Brown  wrote:
> 
> For all the proposals I've seen on this topic, I have to say -1.
> 
> While I agree with the notions surrounding this operator, I've yet to see 
> a better alternative presented, and none that feel truly Swift.
> 
> If someone has a great proposal, though, I look forward to seeing it.
> 
> - Rod
> 
>> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>>  wrote:
>> 
>> -1 for me. None of it looks or feels like Swift, more like Haskell. I 
>> would prefer a library solution for now and remove ?: from the language 
>> and add a which into the standard library and see how that goes and if 
>> there is need for more.
>> 
>> Sorry,
>> 
>> Howard.
>> 
>>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>>  wrote:
>>> 
>>> Any feedback on this? I am rethinking the idea of #( because of the # 
>>> prior usage as a preprocessor directive, but like how it stands out and 
>>> has a meaning.  If no feedback, does it make sense to update my 
>>> proposal with these ideas? Or does this feel like the wrong direction. 
>>> 
>>> 
 On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  
 wrote:
 
 Some more ideas, this moves away from the notion that we should make 
 it look really close to the ternary but keeps all the benefits of the 
 ternary and improves upon it. Since I have been suggesting a breaking 
 change, it is a good time to rethink it a bit. With this idea a 
 horizontal line (double-dash) separates the control value from the 
 choices, the vertical line (bar) indicates none of the above. 
 
 Rather than use the ?( as I have suggested in the past, I think #( 
 works here, where you can think of it as a numerical index. The 
 advantage of this is, it stands out better and leaves ? for optionals 
 only. This works well with the list form. In the enum case the index 
 is the enum key. I can see 

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

[Thorsten Seitz via swift-evolution]

In addition to the problems that you already cited, a library could not check 
exhaustiveness and we would lose pattern matching.

-Thorsten 

> Am 05.01.2016 um 00:53 schrieb Paul Ossenbruggen via swift-evolution 
> :
> 
> Just tried going down this path a bit of creating a library. You can get 
> pretty far for the boolean or integer types, but don’t see a way to do a 
> switch like solution. Also, a big problem with this approach is there is no 
> way to short circuit evaluate the expressions in the list of a variadic 
> function. They will all be evaluated, at the call site. One other problem, so 
> we don’t conflict with the “else” and “default”, keywords, I had to use “def” 
> or “el” for “else". 
> 
> // Simple bool
> func calcB()->String {
> print(“B calculated")
> return "B"
> }
> 
> // Simple bool
> func sel(condition : Bool, @autoclosure _ trueExpr:()->T, @autoclosure _ 
> falseExpr:()->T) -> T {
> return condition ? trueExpr() : falseExpr()
> }
> 
> sel(true, "A", calcB())
> sel(false, "A", calcB())
> 
> // alternative, used "def" for default to not conflict with "else" or 
> “default. This version, may not be necessary.
> func sel(condition : Bool, @autoclosure _ expr:()->T,  @autoclosure 
> el:()->T) -> T {
> return condition ? expr() : el()
> }
> 
> sel(true, "A", el:calcB())
> sel(false, "A", el:calcB())
> 
> // index approach, note the use of autoclosure does not work on array or 
> array of functions. So it will evaluate all expressions at the call site. 
> Unless there is some trick I don’t know. 
> func sel(selector : Int,/* @autoclosure */ _ exprs: T..., def : T) -> T {
> if  selector > exprs.count || selector < 0 {
> return def
> }
> return exprs[selector]
> }
> sel(1, "A", "B", "C", def:"D")
> sel(9, "A", "B", "C", def:"D")
> sel(-1, "A", "B", "C", def:"D")
> 
> 
> 
>> On Jan 4, 2016, at 12:28 PM, Howard Lovatt  wrote:
>> 
>> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
>> prefer a library solution for now and remove ?: from the language and add a 
>> which into the standard library and see how that goes and if there is need 
>> for more.
>> 
>> Sorry,
>> 
>> Howard.
>> 
>>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>>  wrote:
>>> 
>>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>>> usage as a preprocessor directive, but like how it stands out and has a 
>>> meaning.  If no feedback, does it make sense to update my proposal with 
>>> these ideas? Or does this feel like the wrong direction. 
>>> 
>>> 
 On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
 
 Some more ideas, this moves away from the notion that we should make it 
 look really close to the ternary but keeps all the benefits of the ternary 
 and improves upon it. Since I have been suggesting a breaking change, it 
 is a good time to rethink it a bit. With this idea a horizontal line 
 (double-dash) separates the control value from the choices, the vertical 
 line (bar) indicates none of the above. 
 
 Rather than use the ?( as I have suggested in the past, I think #( works 
 here, where you can think of it as a numerical index. The advantage of 
 this is, it stands out better and leaves ? for optionals only. This works 
 well with the list form. In the enum case the index is the enum key. I can 
 see that this however may be a problem because # is used for preprocessor 
 like directives. I am suggesting though just the #( sequence is treated 
 differently. Or the ?( is fine with me as well.
 
 I have gone through a lot of options, some others I looked at are !( which 
 could be read as "match stick” paren, where the word “match” matches a 
 case, I am pretty sure that would not be considered any better than ?( 
 because it is used for optionals. Another is “witch hat paren” ^( which 
 can be read as “which”.  This might create a parse problem with "power of" 
 though, which maybe using ^[ (hat square bracket) could resolve that but 
 not sure if that would create other problems. Some other choices would be 
 &(  and @( but did not choose them because  they don’t have meaning to me 
 but they do have the advantage of standing out like the #(. 
 
 let fa = #(truth -- 1 | 0) // boolean case. 
 let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
 form, pick index, zero based. 
 let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
 0xFF) // enum form.
 let fd = #(color -- .Red:0xFF, 
.Green:  0x00FF00, 
.Blue:   0xFF 
| 0xFF) // enum multiline, default: can be used here if 
 preferred.
 let fe = #(color -- .Red:0xFF, 

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[Jeremy Pereira via swift-evolution]

> On 5 Jan 2016, at 13:42, James Campbell  wrote:
> 
> So the [Int]() is shorthand for Array()

Yes. In general, you can write [T] anywhere you can write Array and [U : V] 
anywhere you can write Dictionary. The are both syntactic sugar.


> 
> On Tue, Jan 5, 2016 at 1:01 PM, Jeremy Pereira 
>  wrote:
> 
> > On 5 Jan 2016, at 12:51, James Campbell  wrote:
> >
> > The problem for me is that is so counter intuitive I didn't even know you 
> > could do that.
> 
> The first one is a bit counter intuitive and I agree that
> 
> var distanceCache: [Int: Int] = []
> 
> might be an improvement, albeit not one I think many people would agree is 
> worth doing. However, the second one is a natural extrapolation from the 
> equivalent array syntax i.e.
> 
> var array = [Int]()
> var dictionary = [String: Int]()
> 
> >
> > On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira 
> >  wrote:
> > I don’t understand what the problem is
> >
> > > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution 
> > >  wrote:
> > >
> > > See this code:
> > > var distanceCache: [Int: Int] = Dictionary()
> > >
> > > It is very long and tedious to write especially if what I am storing 
> > > changes.
> > >
> > > I propose we be allowed to do the following:
> > > var distanceCache: [Int: Int] = []
> >
> > You can do
> >
> > var distanceCache: [Int: Int] = [:]
> >
> > Also
> >
> > var distanceCache2 = [Int: Int]()
> >
> >
> > > Perhaps this dictionary syntax is just confusing and it was a bad idea to 
> > > make it the same as an array. Most languages use "{" so why did swift 
> > > choose to share "[" with arrays and dictionaries.
> >
> > It’s not the same, you need the colons inside. I imagine that braces were 
> > discarded on the grounds that it would confuse the compiler with respect to 
> > closures, for example
> >
> > var myClosure = {} // is a variable of type () -> ()
> >
> >
> > >
> > > --
> > >  Wizard
> > > ja...@supmenow.com
> > > +44 7523 279 698
> > >  ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
> >
> > --
> >  Wizard
> > ja...@supmenow.com
> > +44 7523 279 698
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Tino Heth via swift-evolution]

> The “type parameter list” syntax is sugar that could be implemented as a 
> layer on top of the current proposal or could be implemented orthogonally.
Hi Howard,
I've heard this argument before, so I'll repeat my answer as well:
Both offers don't make sense, it's either one way or the other (or something 
completely different).
If diversity starts here, why not have "const" and "val" beside "let", or allow 
"fn" and "lambda"?

@Matthew: Please, if you support something, then say so - using clear words, 
not phrases like "could be implemented".

Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 12:37 PM, Marcelo Alves via swift-evolution 
>  wrote:
> 
> 
>> On Jan 5, 2016, at 16:06, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>> 
>>> Am 05.01.2016 um 18:12 schrieb Matthew Johnson >> >:
>>> 
>>> 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: 0xFF
>> 
>> 
>>> 
>>> Is anybody going to write up a proposal for the ternary-like switch 
>>> expression?
>>> 
>> 
>> I’ll give it a try.
> 
> Any reason to not use switch let x = color … ? We already have if let, guard 
> let, so I think switch let is pretty “swift-ly”.

Because this would only work when binding a name and not anywhere else.  If 
that restriction is desired this might not be a bad idea.  But if we want an 
expression that can be used anywhere it will not suffice.

> 
> :: marcelo.alves
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Chris Lattner via swift-evolution]

> On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> Everyone, 
> 
> The sticking point here is that xcode generates the first syntax 
> automatically. 
> 
> Simply filing a radar about this would be useless, so I believe the original 
> proposal is meant to sort-of "light a fire" under the Xcode team; by 
> introducing a new language feature they would be forced to support it. 
> 
> Personally, I think it should just be fixed in Xcode as well, but it's not 
> that simple. 

FWIW, the algorithms used by Swift’s code completion in Xcode are part of 
sourcekit, which is included in Swift.org.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Paul Cantrell via swift-evolution]

A few requests for clarification from the proposal authors:

1. The proposal talks in several places about “test modules” (for example, 
“test-module is created per subdirectory of Tests”). How do these test modules 
interact with Package.swift? Does each of them have a separate target? If so, 
how is the test module name specified in the Target(…) entry?

2. Perhaps answered by #1, how does Package.swift specify test-only 
dependencies (e.g. Quick) that are necessary to build tests, but should not be 
exported to downstream projects?

3. You propose that “building a module also builds that module's corresponding 
tests.” Does this apply only to the top-level package, or to all of its 
dependencies? For example, if my FooApp depends on BarLib, and BarLib’s tests 
depend on HugeFancyTestFramework, do I have to download and compile 
HugeFancyTestFramework in order to build FooApp? (Hopefully not!)

I apologize if these questions are already answered in the proposal. I’m not 
sure I caught every subtlety of the writeup.

Cheers,

Paul


> On Jan 5, 2016, at 1:06 PM, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of “Swift Testing” for the Package Manager begins now and runs 
> through Thursday, January 7th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md
> 
> For this particular review, please note that a significant amount of 
> discussion history is available in the original pull request for the proposal:
> 
>   https://github.com/apple/swift-evolution/pull/51
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
>   - Rick
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> Am 05.01.2016 um 18:12 schrieb Matthew Johnson :
> 
> 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: 0xFF
 
 
> 
> Is anybody going to write up a proposal for the ternary-like switch 
> expression?
> 

I’ll give it a try.

-Thorsten

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Goffredo Marocchi via swift-evolution]

> That said, personally, my feeling is that the momentum here in the broad 
> family of C languages (including things like Java) is very strong, and that 
> diverging from that would be extremely problematic.  I don’t see any “active" 
> problems with our current names.  If this is a matter of aesthetics, or an 
> attempt to align with Ruby/Python/Go instead of C/Java etc, then this seems 
> like the wrong direction for Swift.


Losing alignment to C-like paradigms is a valid concern, but then removing 
unwary decrement and increment operators feels out of place... Sad to have seen 
it culled.

Sent from my iPhone

> On 5 Jan 2016, at 18:40, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution 
>>  wrote:
>> Hi all,
>> 
>> I'm curious how other members of the Swift community feel about the clarity 
>> of the "Double" and "Float" type names. It seems incongruous that the 
>> default type for integers is "Int", but the default type for floating point 
>> numbers is not "Float”.
> 
>> Discussion:
>> 
>> I understand the origins of these names in single- and double-precision IEEE 
>> floats. But this distinction feels like a holdover from C (and a 32-bit 
>> world), rather than a natural fit for Swift.
> 
> Yes, the proper IEEE names for these would be “Single” and “Double”.  We 
> briefly considered and rejected that.
> 
>> Here are some reasons to keep Double and Float as they are (numbered for 
>> easy reference, but otherwise unordered):
>> "Double" and "Float" are more natural for developers who are "familiar with 
>> C-like languages."
>> A corollary: A 64-bit "Float" type could be confusing to those developers.
> Yes, I think that 64-bit Float would be *actively* confusing to people, and 
> using that name could cause real harm.
> 
>> Here are some reasons to rename these types:
>> The default for a "float literal" in Swift is a 64-bit value. It would feel 
>> natural if that that value were of type "Float".
>> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
>> floating point types. For cases where a size-specific type is needed, a 
>> size-specific name like "Float32" probably makes the intention of the code 
>> more clear (compared to just "Float").
>> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
>> than raw float or double types.
>> There is precedent for "Float" types being 64-bit in other languages like 
>> Ruby, Python and Go (as long as the hardware supports it).
>> What kind of a name for a type is "Double" anyways, amirite?
> Aside from #3 (CGFloat is a distinct type in Swift, not an alias) and #5 :-)  
> I agree with these points.
> 
> That said, personally, my feeling is that the momentum here in the broad 
> family of C languages (including things like Java) is very strong, and that 
> diverging from that would be extremely problematic.  I don’t see any “active" 
> problems with our current names.  If this is a matter of aesthetics, or an 
> attempt to align with Ruby/Python/Go instead of C/Java etc, then this seems 
> like the wrong direction for Swift.
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 5, 2016, at 5:41 AM, Charles Srstka  wrote:
> 
>> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
> 
> I can almost do it right now, just hacking with the Objective-C runtime 
> functions, so I’d think that if you were actually working with the compiler 
> sources, it should be doable. The trouble is on the Swift side; currently 
> there aren’t any reflection features that I can find that work on Swift 
> protocols.

The compiler isn’t the limitation here, it’s the Objective-C runtime. That’s 
somewhat malleable, but making changes there to support a Swift feature affects 
backward deployment.

> @implementation NSObject (Swizzle)

Note that all approaches based on adding categories to a root class require you 
to enumerate root classes, as I noted in my original message. That’s 
unfortunate and requires more trickery.

> + (void)load {
> CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent();
> 
> unsigned int classCount = 0;
> Class *classes = objc_copyClassList();

Doing it this way won’t handle protocol conformances or classes loaded later 
via a dlopen’d dylib.

> 
> Protocol *proto = @protocol(HasSwiftExtension);
> 
> for (unsigned int i = 0; i < classCount; i++) {
> Class eachClass = classes[i];
> 
> if (class_conformsToProtocol(eachClass, proto)) {
> unsigned int protoCount = 0;
> Protocol * __unsafe_unretained *protocols = 
> class_copyProtocolList(eachClass, );
> 
> for (unsigned int j = 0; j < protoCount; j++) {
> Protocol *eachProto = protocols[j];
> 
> if (protocol_conformsToProtocol(eachProto, proto)) {
> unsigned int methodCount = 0;
> // what we would want would be to pass YES for 
> isRequiredMethod; unfortunately,
> // adding optional methods to an @objc protocol in an 
> extension currently just
> // crashes the compiler when I try it. So pass NO, for 
> the demonstration.

The crash is a bug; please file it.

> struct objc_method_description *methods = 
> protocol_copyMethodDescriptionList(eachProto, NO, YES, );
> 
> for (unsigned int k = 0; k < methodCount; k++) {
> struct objc_method_description method = methods[k];
> 
> if (!class_respondsToSelector(eachClass, 
> method.name)) {
> [SwizzleWrapper swizzleClass:[eachClass class] 
> protocol:eachProto method:method];
> }
> }
> 
> free(methods);
> }
> }
> 
> free(protocols);
> }
> }
> 
> free(classes);
> 
> NSLog(@"took %f seconds", CFAbsoluteTimeGetCurrent() - startTime);
> }
> @end
> 

[snip]

> (For the record, I’m not advocating actually using the swizzling method 
> described above; just pointing out that intercepting the selector is 
> possible. Working with the compiler sources, I’d expect more elegant 
> solutions would be possible.)


There are better mechanisms for this than +load. But one would have to deal 
with the dylib loading issue and the need to enumerate root classes to get to a 
complete implementation. Frankly, I don’t think this level of Objective-C 
runtime hackery is worth the effort, hence my suggestion to make the existing 
behavior explicit.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[David Owens II via swift-evolution]

+1. I think it brings a nice symmetry with the integer types and puts size 
classing in a more consistent place.

And to be frank, I already typedef the intrinsic float/double types in my C 
code to f32/f64 for similar reasons.

-David

> On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I'm curious how other members of the Swift community feel about the clarity 
> of the "Double" and "Float" type names. It seems incongruous that the default 
> type for integers is "Int", but the default type for floating point numbers 
> is not "Float".
> 
> What if the name "Float" were given to the intrinsic, 64-bit floating point 
> type? (And the existing "Float" and "Double" names were removed in favor of 
> "Float32" and "Float64"?)
> 
> 
> Discussion:
> 
> I understand the origins of these names in single- and double-precision IEEE 
> floats. But this distinction feels like a holdover from C (and a 32-bit 
> world), rather than a natural fit for Swift.
> 
> Here are some reasons to keep Double and Float as they are (numbered for easy 
> reference, but otherwise unordered):
> "Double" and "Float" are more natural for developers who are "familiar with 
> C-like languages."
> A corollary: A 64-bit "Float" type could be confusing to those developers.
> Another corollary: Swift needs to interoperate with Objective C, and its 
> "float" and "double" types.
> Renaming these types would open the door to bike-shedding every type name and 
> keyword in the language.
> Changing the meaning of an existing type ("Float") would be a bit PITA for 
> existing code (although an automated migration from "Float" to "Float32" and 
> "Double" to "Float" should be possible).
> Renaming a fundamental type would take considerable effort.
> Here are some reasons to rename these types:
> The default for a "float literal" in Swift is a 64-bit value. It would feel 
> natural if that that value were of type "Float".
> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
> floating point types. For cases where a size-specific type is needed, a 
> size-specific name like "Float32" probably makes the intention of the code 
> more clear (compared to just "Float").
> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
> than raw float or double types.
> There is precedent for "Float" types being 64-bit in other languages like 
> Ruby, Python and Go (as long as the hardware supports it).
> What kind of a name for a type is "Double" anyways, amirite?
> (that last one is a joke, BTW)
> 
> What do you think? Do you agree or disagree with any of my assessments? Are 
> there any pros or cons that I've missed? Is the level of effort so large that 
> it makes this change impractical? Is it a colossal waste of human effort to 
> even consider a change like this?
> 
> Thanks for your time and attention,
> Alex Johnson (@nonsensery)
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Chris Lattner via swift-evolution]

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution 
 wrote:
> Hi all,
> 
> I'm curious how other members of the Swift community feel about the clarity 
> of the "Double" and "Float" type names. It seems incongruous that the default 
> type for integers is "Int", but the default type for floating point numbers 
> is not "Float”.

> Discussion:
> 
> I understand the origins of these names in single- and double-precision IEEE 
> floats. But this distinction feels like a holdover from C (and a 32-bit 
> world), rather than a natural fit for Swift.

Yes, the proper IEEE names for these would be “Single” and “Double”.  We 
briefly considered and rejected that.

> Here are some reasons to keep Double and Float as they are (numbered for easy 
> reference, but otherwise unordered):
> "Double" and "Float" are more natural for developers who are "familiar with 
> C-like languages."
> A corollary: A 64-bit "Float" type could be confusing to those developers.
Yes, I think that 64-bit Float would be *actively* confusing to people, and 
using that name could cause real harm.

> Here are some reasons to rename these types:
> The default for a "float literal" in Swift is a 64-bit value. It would feel 
> natural if that that value were of type "Float".
> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
> floating point types. For cases where a size-specific type is needed, a 
> size-specific name like "Float32" probably makes the intention of the code 
> more clear (compared to just "Float").
> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
> than raw float or double types.
> There is precedent for "Float" types being 64-bit in other languages like 
> Ruby, Python and Go (as long as the hardware supports it).
> What kind of a name for a type is "Double" anyways, amirite?
Aside from #3 (CGFloat is a distinct type in Swift, not an alias) and #5 :-)  I 
agree with these points.

That said, personally, my feeling is that the momentum here in the broad family 
of C languages (including things like Java) is very strong, and that diverging 
from that would be extremely problematic.  I don’t see any “active" problems 
with our current names.  If this is a matter of aesthetics, or an attempt to 
align with Ruby/Python/Go instead of C/Java etc, then this seems like the wrong 
direction for Swift.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 12:06 PM, Thorsten Seitz  wrote:
> 
> 
>> Am 05.01.2016 um 18:12 schrieb Matthew Johnson > >:
>> 
>> 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: 0xFF
> 
> 
>> 
>> Is anybody going to write up a proposal for the ternary-like switch 
>> expression?
>> 
> 
> I’ll give it a try.

Sounds good.  I’ll be happy to review a draft if you would find that helpful.

> 
> -Thorsten
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Matthew Johnson via swift-evolution]

> On Jan 5, 2016, at 12:12 PM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> The “type parameter list” syntax is sugar that could be implemented as a 
>> layer on top of the current proposal or could be implemented orthogonally.
> Hi Howard,
> I've heard this argument before, so I'll repeat my answer as well:
> Both offers don't make sense, it's either one way or the other (or something 
> completely different).

I don’t think it’s clear whether both make sense or not.  They are not mutually 
exclusive and are aimed at solving related, but different problems.  If we 
adopt the current proposal, the Kotlin / Scala syntax *might* make sense for 
some use cases.  It would depend upon whether the current proposal is 
considered too verbose in enough cases or not.  This may or may not turn out to 
be the case.

The reason my proposal looks the way it does is because there are specific 
goals it intends to achieve and problems it is intended to solve.  These goals 
and problems are not adequately addressed by the Kotlin / Scala syntax.

> If diversity starts here, why not have "const" and "val" beside "let", or 
> allow "fn" and "lambda"?
> 
> @Matthew: Please, if you support something, then say so - using clear words, 
> not phrases like "could be implemented”.

This phrasing is plenty clear IMO.  I am stating a possibility.  I do not have 
a position on whether or not it is a good idea at the moment.

I have made some modifications to the proposal over the last few days.  These 
changes have been partly motivated by considering the conversation we have had. 
 You may wish to give it another look.  If so, please look here: 
https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/0018-flexible-memberwise-initialization.md
 
.
  There is currently an open PR for the latest change so it is not in the main 
Swift evolution repo yet.

The most recent change includes a discussion of why it does not use the Scala / 
Kotlin syntax.  You may not like the choice but I hope you can at least 
understand the rationale (even if you disagree with it).


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Marcelo Alves via swift-evolution]

> On Jan 5, 2016, at 16:06, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>> Am 05.01.2016 um 18:12 schrieb Matthew Johnson > >:
>> 
>> 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: 0xFF
> 
> 
>> 
>> Is anybody going to write up a proposal for the ternary-like switch 
>> expression?
>> 
> 
> I’ll give it a try.

Any reason to not use switch let x = color … ? We already have if let, guard 
let, so I think switch let is pretty “swift-ly”.

:: marcelo.alves___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Rick Ballard via swift-evolution]

Hello Swift community,

The review of “Swift Testing” for the Package Manager begins now and runs 
through Thursday, January 7th. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md

For this particular review, please note that a significant amount of discussion 
history is available in the original pull request for the proposal:

https://github.com/apple/swift-evolution/pull/51

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

- Rick
  Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

[Kevin Ballard via swift-evolution]

On Tue, Jan 5, 2016, at 10:47 AM, Chris Lattner via swift-evolution wrote:
> 
> > On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution 
> >  wrote:
> > 
> > Everyone, 
> > 
> > The sticking point here is that xcode generates the first syntax 
> > automatically. 
> > 
> > Simply filing a radar about this would be useless, so I believe the 
> > original proposal is meant to sort-of "light a fire" under the Xcode team; 
> > by introducing a new language feature they would be forced to support it. 
> > 
> > Personally, I think it should just be fixed in Xcode as well, but it's not 
> > that simple. 
> 
> FWIW, the algorithms used by Swift’s code completion in Xcode are part of 
> sourcekit, which is included in Swift.org.

Oh really? So I could actually go in there and fix it to stop generating 
closures that look like

foo { () -> Void in
<#code#>
}

(the `() -> Void in` is rather pointless)

In that case, I suppose it makes sense to actually discuss proposed code 
completion changes on this list. On the subject of disabling trailing closure 
syntax, it might make sense to have Xcode not use it automatically when the 
function has 2 closure parameters (sometimes I do want the second closure to be 
trailing-closure, sometimes I don't, but it seems reasonable to err on the side 
of not having it be trailing-closure if there's more than 1 closure in the 
call).

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[John Joyce via swift-evolution]

> On Jan 6, 2016, at 4:06 AM, Rick Ballard via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?
Overall this is great direction, but needs more deliberation and sifting about 
the details. This kind of infrastructure will live a while, or if it ends up 
stinky, will go unused.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Not really a language change as far as I can tell.

>   * Does this proposal fit well with the feel and direction of Swift?
Definitely.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
This is an excellent addition that keeps the whole life cycle view in.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 



On Build Configuration/Testability
This seems to be a fairly narrow view, but maybe it's enough.
I think release and debug are not the only configurations, though likely the 
most common set.
Perhaps some sensible defaults should be implicit (written automatically in a 
PM file) but customizable? 
(apologies if this exists and I missed it.)

Additionally, this takes a narrow view on the nature of testing. 
Unit tests are not the only game in town and I would like to see this left open 
to other kinds of automated testing.
You might have UI testing among others. XCUITest is not the only idea here.
You may need to test interactions and flows between systems.

For the Command Line Interface section
I would suggest the subcommand test makes a lot of sense.

Is there a proper place here somewhere for ensuring a home for test resources? 
(a standardized test/ subdirectory for static/standard test data )

Lovely open ended callouts on the test reporting section.
Important for that to be malleable and replaceable. Might be JSON would be an 
obvious addition there...?

Lastly, should there be any built-in facility for bug/issue tracking 
relationships?
Perhaps too much minutia for this proposal, but seems a good thing to include.
In particular for reporting, any ticket/tracking numbers referring to 
regression tests are always good callouts in manager friendly reporting.


Lastly as an addition, would it make sense to include some kind of 
test/code-coverage element here?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Félix Cloutier via swift-evolution]

I stand corrected.

Félix

> Le 5 janv. 2016 à 22:19:28, Charles Srstka  a écrit 
> :
> 
>> On Jan 5, 2016, at 9:06 PM, Félix Cloutier > > wrote:
>> 
>> The linker is smart enough to get rid of frameworks that you don't actually 
>> use.
>> 
>> Félix
> 
> 
> objc_copyClassList leaves a value of 14694 in classCount. When I just link 
> against Foundation it only gives 1581.
> 
> otool says:
> 
> $ otool -L test
> test:
>   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
> 120.1.0)
>   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
> (compatibility version 300.0.0, current version 1256.1.0)
>   /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 
> (compatibility version 1.0.0, current version 760.2.5)
>   /System/Library/Frameworks/Metal.framework/Versions/A/Metal 
> (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/Contacts.framework/Versions/A/Contacts 
> (compatibility version 0.0.0, current version 0.0.0)
>   /System/Library/Frameworks/GSS.framework/Versions/A/GSS (compatibility 
> version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/CoreMIDIServer.framework/Versions/A/CoreMIDIServer 
> (compatibility version 1.0.0, current version 73.0.0)
>   /System/Library/Frameworks/Python.framework/Versions/2.7/Python 
> (compatibility version 2.7.0, current version 2.7.10)
>   
> /System/Library/Frameworks/CoreLocation.framework/Versions/A/CoreLocation 
> (compatibility version 1.0.0, current version 1615.38.0)
>   /System/Library/Frameworks/GLKit.framework/Versions/A/GLKit 
> (compatibility version 1.0.0, current version 20.0.0)
>   /System/Library/Frameworks/MapKit.framework/Versions/A/MapKit 
> (compatibility version 1.0.0, current version 0.0.0)
>   
> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
>  (compatibility version 1.0.0, current version 756.20.4)
>   
> /System/Library/Frameworks/CoreTelephony.framework/Versions/A/CoreTelephony 
> (compatibility version 1.0.0, current version 0.0.0)
>   /System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit 
> (compatibility version 1.0.0, current version 481.8.0)
>   /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 
> (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/Collaboration.framework/Versions/A/Collaboration 
> (compatibility version 1.0.0, current version 75.0.0)
>   /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 
> (compatibility version 1.0.0, current version 2.4.0)
>   /System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook 
> (compatibility version 1.0.0, current version 1679.3.0)
>   /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook 
> (compatibility version 1.0.0, current version 0.0.0)
>   
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
>  (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 
> (compatibility version 8.5.0, current version 8.5.9)
>   
> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/InputMethodKit.framework/Versions/A/InputMethodKit 
> (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 
> (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/Photos.framework/Versions/A/Photos 
> (compatibility version 1.0.0, current version 350.22.0)
>   /System/Library/Frameworks/OSAKit.framework/Versions/A/OSAKit 
> (compatibility version 1.0.0, current version 104.0.0)
>   
> /System/Library/Frameworks/MediaAccessibility.framework/Versions/A/MediaAccessibility
>  (compatibility version 1.0.0, current version 62.0.0)
>   /System/Library/Frameworks/ContactsUI.framework/Versions/A/ContactsUI 
> (compatibility version 1.0.0, current version 1679.3.0)
>   
> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
>  (compatibility version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
> version 1.0.0, current version 1.0.0)
>   /System/Library/Frameworks/StoreKit.framework/Versions/A/StoreKit 
> (compatibility version 1.0.0, current version 379.0.0)
>   
> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 
> (compatibility version 1.0.0, current version 1.0.0)
>   
> /System/Library/Frameworks/PreferencePanes.framework/Versions/A/PreferencePanes
>  

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Charles Srstka via swift-evolution]

> On Jan 5, 2016, at 9:06 PM, Félix Cloutier  wrote:
> 
> The linker is smart enough to get rid of frameworks that you don't actually 
> use.
> 
> Félix


objc_copyClassList leaves a value of 14694 in classCount. When I just link 
against Foundation it only gives 1581.

otool says:

$ otool -L test
test:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1256.1.0)
/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 
(compatibility version 1.0.0, current version 760.2.5)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Contacts.framework/Versions/A/Contacts 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/GSS.framework/Versions/A/GSS (compatibility 
version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreMIDIServer.framework/Versions/A/CoreMIDIServer 
(compatibility version 1.0.0, current version 73.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python 
(compatibility version 2.7.0, current version 2.7.10)

/System/Library/Frameworks/CoreLocation.framework/Versions/A/CoreLocation 
(compatibility version 1.0.0, current version 1615.38.0)
/System/Library/Frameworks/GLKit.framework/Versions/A/GLKit 
(compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/MapKit.framework/Versions/A/MapKit 
(compatibility version 1.0.0, current version 0.0.0)

/System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
 (compatibility version 1.0.0, current version 756.20.4)

/System/Library/Frameworks/CoreTelephony.framework/Versions/A/CoreTelephony 
(compatibility version 1.0.0, current version 0.0.0)
/System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit 
(compatibility version 1.0.0, current version 481.8.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/Collaboration.framework/Versions/A/Collaboration 
(compatibility version 1.0.0, current version 75.0.0)
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 
(compatibility version 1.0.0, current version 2.4.0)
/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook 
(compatibility version 1.0.0, current version 1679.3.0)
/System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook 
(compatibility version 1.0.0, current version 0.0.0)

/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 
(compatibility version 8.5.0, current version 8.5.9)

/System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/InputMethodKit.framework/Versions/A/InputMethodKit 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Photos.framework/Versions/A/Photos 
(compatibility version 1.0.0, current version 350.22.0)
/System/Library/Frameworks/OSAKit.framework/Versions/A/OSAKit 
(compatibility version 1.0.0, current version 104.0.0)

/System/Library/Frameworks/MediaAccessibility.framework/Versions/A/MediaAccessibility
 (compatibility version 1.0.0, current version 62.0.0)
/System/Library/Frameworks/ContactsUI.framework/Versions/A/ContactsUI 
(compatibility version 1.0.0, current version 1679.3.0)

/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
 (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/StoreKit.framework/Versions/A/StoreKit 
(compatibility version 1.0.0, current version 379.0.0)

/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/PreferencePanes.framework/Versions/A/PreferencePanes 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/GameplayKit.framework/Versions/A/GameplayKit 
(compatibility version 1.0.0, current version 1.0.0)

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Jacob Bandes-Storch via swift-evolution]

Wow! I didn't know that worked. It's a bit surprising, and perhaps not
intended. I think the proposal is still valid.

On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers 
wrote:

> You can shadow self with a guard like you wrote it if use the keyword
> escaping backquotes like so:
>
> guard let `self` = self else { return }
> On Wed, Jan 6, 2016 at 10:55 AM Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
>> strongSelf = self", and 26 occurrences of "self?." (which should arguably
>> be changed to the former).
>>
>> Jacob
>>
>> On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
>> wrote:
>>
>>> +1.
>>>
>>> Merely using "self?.something" repeatedly might produce unexpected
>>> behavior, if self becomes nil between calls. As I mentioned in another
>>> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>>>
>>> In many cases, I use the pattern
>>>
>>> somethingAsync { [weak self] in
>>> guard let strongSelf = self else { return }
>>>
>>> // use strongSelf below
>>> }
>>>
>>> But of course, this leads to the unnatural/unwieldy
>>> "strongSelf.property" all over the place.
>>>
>>> I agree with Jordan that "guard let self = self" isn't the most
>>> satisfying syntax, but it has the advantage of being a *very* minimal
>>> grammar/syntax change, and its behavior is completely clear as long as the
>>> user is already familiar with guard.
>>>
>>> We should also consider whether "self." is required after "guard let
>>> self = self". An explicit "guard let self = self" avoids the
>>> accidental-capture problem, so I think it's reasonable to allow unqualified
>>> property access for the remainder of the scope.
>>>
>>> Jacob
>>>
>>> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 This has come up before, in a thread called "Proposal: weakStrong self
 in completion handler closures". I'm still not 100% happy with the
 syntax, but I like that "guard let" can handle non-Void non-Optional
 returns well, while 'weakStrong' cannot.

 Jordan


 On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
 swift-evolution@swift.org> wrote:

 Currently, weakly captured `self` cannot be bound to `guard let …` with
 same name, and emits a compiler error.

 class Foo {
 func test2(f: ()->()) {
 // …
 }
 func test1() {
 test2 { [weak self] in
 guard let self = self else { return } // Error.
 print(self)
 }
 }
 }

 Do we have any reason to disallow making `self` back to strong
 reference? It’d be nice if I can do it. Please consider this case.

 class Foo {
 func getValue1() -> Int {
 return 1234
 }
 func test3(value: Int) {
 print(value)
 }
 func test2(f: ()->()) {
 // …
 }
 func test1() {
 test2 { [weak self] in
 self?.test3(self?.getValue1()) // Doesn't work because it's not
 unwrapped.

 self!.test3(self!.getValue1()) // Considered harmful due to `!`.

 guard self != nil else { return }
 self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.

 guard let self1 = self else { return }
 self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
 new name `self1`.

 guard let self = self else { return }
 self.test3(self.getValue1()) // OK.

 }
 }
 }

 This also can be applied to `if let` or same sort of constructs.

 Even further, we can consider removing required reference to `self`
 after `guard let …` if appropriate.

 guard let self = self else { return }
 test3(getValue1()) // Referencing to `self` would not be required
 anymore. Seems arguable.

 I think this is almost fine because users have to express their
 intention explicitly with `guard` statement. If someone erases the `guard`
 later, compiler will require explicit self again, and that will prevent
 mistakes. But still, I am not sure this removal would be perfectly fine.

 I am not sure whether this is already supported or planned. But lacked
 at least in Swift 2.1.1.

 — Hoon H.















 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution



 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution


>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

[Xiaodi Wu via swift-evolution]

> This has been suggested before, usually in the form of a separate
`implement` keyword. The main problem is that it makes it impossible to
write a protocol after the fact which formalizes some existing pattern in
the types.

I think this is a great point and would be a con that I hadn't considered
in terms of Howard's suggestion that everything implementing a protocol
should have use a keyword (such as "override" or "implement").

I fear that I've explained my idea a little poorly. My thought was that
*only methods overriding something*--namely, a default implementation given
in a protocol extension--should be required to use the override keyword
when the method is dynamically dispatched.

It would remain very much possible to formalize an existing pattern
because, in the case of your example (unless I'm misunderstanding?), you
are not also providing a default implementation of the "min" and "max"
getters, and the IntXX structs would have nothing to override. Indeed,
you'd hardly be formalizing an existing pattern if you had to supply de
novo implementations! It's true that it's possible to do something in
today's Swift syntax that wouldn't be possible in my proposal. Namely, in
today's Swift syntax, it's possible to give a dynamically dispatched
default implementation of the min and max getters in an after-the-fact
formalization, but I have trouble seeing any circumstance in which that
would be necessary--unless I misunderstand, such a default implementation
can never be invoked?


On Tue, Jan 5, 2016 at 10:50 PM, Brent Royal-Gordon 
wrote:

> > Taking inspiration from syntax used for methods in classes that override
> methods in superclasses, require methods that override dynamically
> dispatched default implementations in protocol extensions to use the
> override keyword. Likewise, forbid the override keyword if the method being
> implemented instead 'masks' (would that be the right word?) a statically
> dispatched method in a protocol extension which can nonetheless be invoked
> by upcasting to the protocol.
>
> This has been suggested before, usually in the form of a separate
> `implement` keyword. The main problem is that it makes it impossible to
> write a protocol after the fact which formalizes some existing pattern in
> the types.
>
> What do I mean by that? Well, imagine you need generic access to the `min`
> and `max` static properties of the various integer types. There's no
> existing protocol that includes those members. But you can write one and
> then extend the integer types to conform to your new protocol:
>
> protocol BoundedIntegerType: IntegerType {
> static var min: Self { get }
> static var max: Self { get }
> }
> extension Int: BoundedType {}
> extension Int8: BoundedType {}
> extension Int16: BoundedType {}
> extension Int32: BoundedType {}
> extension Int64: BoundedType {}
>
> func printLowestPossibleValueOfValue BoundedIntegerType>(x: Integer) {
> print(Integer.min)
> }
>
> This only works because `min` and `max` *don't* need any special marking
> to be used to satisfy a requirement. Requiring a keyword like you suggest
> would remove that feature.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

[Brent Royal-Gordon via swift-evolution]

> As an OS X and iOS developer, it sometimes seems that I work with 
> [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or 
> String.  I’d love to see Swift’s standard library include Rect, Point, and 
> Size types, with bridging to make them “just work” with any UIKit or AppKit 
> API that expects their NS or CG equivalents.  Maybe also typealias Frame and 
> Bounds to Rect while we’re at it.
> 
> Thoughts?

My main thought is that, although I use these types in my iOS and Mac apps all 
the time, I think I've used a rectangle type in web development maybe once 
(when I was generating images). Swift is currently used mainly for GUI 
programming, but most of the domains it's expanding into are ones where it 
doesn't need those types.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Ossenbruggen via swift-evolution]

Heh, one other thought. Pretty sure this was rejected by the switch statement 
but if keeping it concise for expressions is a goal then _ might make sense for 
the default case especially with this form. :-) 

let fh = ?(color, .Red: 0xFF // only one expression can be the result here 
so case is unnecessary. 
  .Green: 0x00FF00
  .Blue: 0xFF
  _: 0xFF) // default is always last, unless all cases are 
handled. 

I agree with it being rejected for the statement form, but kinda makes sense 
here. 

> On Jan 5, 2016, at 10:50 PM, Paul Ossenbruggen  wrote:
> 
> The thing I don’t like is the repeated use of case. and default. This, I 
> think makes the expression longer than it needs to be. For expressions it is 
> not necessary because you only have one expression which returns one value, 
> where as in a statement you have multiple statements following it, so it is 
> necessary to separate the cases with the word “case”. I think trying to 
> reduce clutter is important. 
> 
> For example, statements have to deal with multiple statements per case. 
> 
> let color = Colors.Red
> // hello
> let res : Int
> switch color {
> case .Red:
>   res = 0xFF
>   print(res) // case is necessary here to separate statement lists. 
> case .Green: 
>   res =  0x00FF00
>   print(res)
> case .Blue: 
>   res = 0xFF
>   print(res)
> default:
> res = 0xFF
> }
> 
> This is why I went down the path of trying to group it with parenthesis and 
> optionally remove the word case. I know it may seem a little less like a 
> "switch" but I think having to write out “case" over and over is not great 
> when it does not serve the same purpose as it does in the statement form. So 
> in the compact form: 
> 
> let fh = ?(color, .Red: 0xFF // only one expression can be the result 
> here so case is unnecessary. 
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   : 0xFF) // default is always last, unless all cases are 
> handled. 
> 
> 
> This seems more light and more and just as understandable as Thorsten's 
> suggestion. (Note: I keep playing with the separators because the feedback 
> was, my latest suggestions were not Swift like). Also, it is possible to drop 
> the “case" in this structure and it can be read more like a function if 
> desired. My suggestion also supported this form but its only advantage is 
> that it looks more like a “switch", there may be value in that but I think 
> conciseness and less clutter should win:
> 
> let fh = ?(color, case .Red: 0xFF
>   case .Green: 0x00FF00
>   case .Blue: 0xFF
>   default: 0xFF)
> 
> Not sure though if people don’t like having alternatives forms though.
> 
> I think there is value in having a consistent way of doing index based as 
> well as boolean based expressions as I have suggested in my proposal. I know 
> that is a harder thing to push for but I think it is a win. I have 
> backpedaled on some of my weirder character choices here so it more like the 
> ternary. 
> 
> let fb = ?(pickOne, “A", "B", "C", "D", "E", "F", "G” : "Z")
> let fe = ?(truthy == truth, “unlikely” : “likely")
> 
> If you look at these suggestions above, I have only moved one ? added a 
> comma, and added parenthesis to the ternary. I think these latest suggestions 
> look more like Swift and more like the ternary than my last email.
> 
> If it is really preferred the control value could be moved outside the parens 
> but I think it makes it harder to find the beginning and end of the ternary 
> and it does not have the advantage of the function like feel to it:. 
> 
> let fe = truthy == truth ?(“unlikely” : “likely")
> 
> let fh = color ?( .Red: 0xFF
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   : 0xFF) 
> 
> finally we could drop the parenthesis all together and the ternary is back in 
> original form, which results in Thorsten’s suggestion minus the cases,
> 
> let fe = truthy == truth ? “unlikely” : “likely"
> 
> let fh = color ? .Red: 0xFF
>  .Green: 0x00FF00
>  .Blue: 0xFF
>  : 0xFF 
> 
> I think the parenthesis and the control inside the construct really help and 
> this may be hard to parse without the grouping the parenthesis provides. I 
> don’t think we are that far apart though. 
> 
> - Paul 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Kevin Ballard via swift-evolution]

I actually expected it to create a different identifier that is
unrelated to the keyword, so you can refer to `self` with backticks in
the future to get the version bound by the guard, and self as a keyword
to get the original value of self.

Not that I think this is particularly useful, of course...

-Kevin Ballard

On Tue, Jan 5, 2016, at 08:42 PM, Greg Parker via swift-evolution wrote:
> I think it is a bug  :-)  That's not what backquotes are for. It ought
> to be either supported without the backquotes or banned regardless of
> backquotes.
>
>> On Jan 5, 2016, at 8:34 PM, Jacob Bandes-Storch
>>  wrote:
>>
>> Yes, it seems to use the strong shadowing variable. (The compiler
>> doesn't complain about "self.foo", and "self?.foo" becomes invalid
>> because self is no longer optional.)
>>
>> If it weren't so useful, I'd call it a bug.
>>
>> On Tue, Jan 5, 2016 at 8:34 PM, Greg Parker
>>  wrote:
>>> Does further use of self after that actually use a strong shadowing
>>> variable? Or does it go back to the weak reference it already had as
>>> if the shadow were not there?
>>>
>>>
 On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution
  wrote:

 Wow! I didn't know that worked. It's a bit surprising, and perhaps
 not intended. I think the proposal is still valid.

 On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers
  wrote:
> You can shadow self with a guard like you wrote it if use the
> keyword escaping backquotes like so:
>
> guard let `self` = self else { return }
>>>
>
>
> _
> swift-evolution mailing list swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Charles Srstka via swift-evolution]

> On Jan 5, 2016, at 8:29 PM, Greg Parker  wrote:
> 
>> 
>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution 
>> > wrote:
>> 
>>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor >> > wrote:
>>> 
>>> There are better mechanisms for this than +load. But one would have to deal 
>>> with the dylib loading issue and the need to enumerate root classes to get 
>>> to a complete implementation. Frankly, I don’t think this level of 
>>> Objective-C runtime hackery is worth the effort, hence my suggestion to 
>>> make the existing behavior explicit.
>> 
>> Yeah, +load was just to throw together a quick-and-dirty demonstration, and 
>> not what you’d actually use. You have a point about libraries and bundles; 
>> you’d have to hook into that and rescan each time new code was dynamically 
>> loaded. However, the enumeration of classes only seems to take around 0.001 
>> seconds, so I don’t think it’s terrible.
> 
> Enumeration of classes is terrible: it forces the runtime to perform lots of 
> work that it tries very hard to perform lazily otherwise. I would expect your 
> measured cost to be much higher if you had linked to more high-level 
> libraries (UIKit, MapKit, etc).

That was my gut reaction to the idea also, when I had it, but it seems to run 
pretty fast no matter what I do. I just tried dragging every framework from 
/System/Library/Frameworks into the project, removing only the Java frameworks, 
Kernel.framework, Message.framework, and vecLib.framework. Time taken was 
0.004260 seconds.

It is, of course, ugly and hacky as hell, and that might make a pretty good 
reason not to do it. :-/ What do you think about the other idea, of adding to 
NSObject’s default implementation of +resolveInstanceMethod:? That *would* be 
done lazily, and would avoid all the problems involving dynamically loaded code.

Charles___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0014 Constraining `AnySequence.init`

[Douglas Gregor via swift-evolution]

The review of SE-0014 "Constraining `AnySequence.init`" ran from December 
18–21, 2015. The proposal has been accepted for Swift 2.2.


https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md

Thank you to everyone who participated in the review process! We welcome an 
implementation of this proposal, which is tracked by

https://bugs.swift.org/browse/SR-474

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

> What is your evaluation of the proposal?

+1 for changing the name, but -1 for "associatedtype" in particular.
Alternate suggestions:

   - associatedType Element
   - associated_type Element
   - associated type Element
   - associated Element
   - type Element
   - having Element


> Is the problem being addressed significant enough to warrant a change to
Swift?

Yes.


> Does this proposal fit well with the feel and direction of Swift?

I don't feel that the multi-word-yet-all-lowercase name fits with the rest
of the Swift language. See alternate suggestions above.


> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Extensive experience with the feature, but I have mostly just skimmed the
emails in this (and the preceding) thread.

- Jacob

On Sat, Jan 2, 2016 at 10:38 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "Replace `typealias` keyword with `associatedtype` for
> associated type declarations” begins now and runs through Wednesday,
> January 6th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Cheers,
> Doug Gregor
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Félix Cloutier via swift-evolution]

The linker is smart enough to get rid of frameworks that you don't actually use.

Félix

> Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution 
>  a écrit :
> 
>> On Jan 5, 2016, at 8:29 PM, Greg Parker > > wrote:
>> 
>>> 
>>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
 On Jan 5, 2016, at 11:52 AM, Douglas Gregor > wrote:
 
 There are better mechanisms for this than +load. But one would have to 
 deal with the dylib loading issue and the need to enumerate root classes 
 to get to a complete implementation. Frankly, I don’t think this level of 
 Objective-C runtime hackery is worth the effort, hence my suggestion to 
 make the existing behavior explicit.
>>> 
>>> Yeah, +load was just to throw together a quick-and-dirty demonstration, and 
>>> not what you’d actually use. You have a point about libraries and bundles; 
>>> you’d have to hook into that and rescan each time new code was dynamically 
>>> loaded. However, the enumeration of classes only seems to take around 0.001 
>>> seconds, so I don’t think it’s terrible.
>> 
>> Enumeration of classes is terrible: it forces the runtime to perform lots of 
>> work that it tries very hard to perform lazily otherwise. I would expect 
>> your measured cost to be much higher if you had linked to more high-level 
>> libraries (UIKit, MapKit, etc).
> 
> That was my gut reaction to the idea also, when I had it, but it seems to run 
> pretty fast no matter what I do. I just tried dragging every framework from 
> /System/Library/Frameworks into the project, removing only the Java 
> frameworks, Kernel.framework, Message.framework, and vecLib.framework. Time 
> taken was 0.004260 seconds.
> 
> It is, of course, ugly and hacky as hell, and that might make a pretty good 
> reason not to do it. :-/ What do you think about the other idea, of adding to 
> NSObject’s default implementation of +resolveInstanceMethod:? That *would* be 
> done lazily, and would avoid all the problems involving dynamically loaded 
> code.
> 
> Charles
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Greg Parker via swift-evolution]

Does further use of self after that actually use a strong shadowing variable? 
Or does it go back to the weak reference it already had as if the shadow were 
not there?

> On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Wow! I didn't know that worked. It's a bit surprising, and perhaps not 
> intended. I think the proposal is still valid.
> 
> On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers  > wrote:
> You can shadow self with a guard like you wrote it if use the keyword 
> escaping backquotes like so:
> 
> guard let `self` = self else { return }


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

[Félix Cloutier via swift-evolution]

NSRect and CGRect are already the same type and can be used interchangeably:

> typedef CGRect NSRect;


You can easily typealias CGRect to Rect as well if you don't like the 
two-letter prefix. Otherwise, if you can wait a bit, SE-0005 

 will probably do it for you since it should remove the NS prefix 

 on Foundation APIs.

I'm ot particularly enthusiastic about the suggested Frame and Bounds 
typealiases though. You could still assign a Bounds to a Frame so I don't think 
that there's a big win here.

Félix

> Le 6 janv. 2016 à 00:10:31, John Randolph via swift-evolution 
>  a écrit :
> 
> Sorry if this is a repeat, but I’d like to suggest promoting certain structs 
> from Foundation to the Swift standard library.
> 
> As an OS X and iOS developer, it sometimes seems that I work with 
> [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or 
> String.  I’d love to see Swift’s standard library include Rect, Point, and 
> Size types, with bridging to make them “just work” with any UIKit or AppKit 
> API that expects their NS or CG equivalents.  Maybe also typealias Frame and 
> Bounds to Rect while we’re at it.
> 
> Thoughts?
> 
> -jcr
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

[Thorsten Seitz via swift-evolution]

> Am 06.01.2016 um 06:23 schrieb Xiaodi Wu via swift-evolution 
> :
> 
> It would remain very much possible to formalize an existing pattern because, 
> in the case of your example (unless I'm misunderstanding?), you are not also 
> providing a default implementation of the "min" and "max" getters, and the 
> IntXX structs would have nothing to override. Indeed, you'd hardly be 
> formalizing an existing pattern if you had to supply de novo implementations!

The pattern might exist for some existing classes or structs but it might still 
be useful for new classes or even for some existing ones to provide a default 
implementation.

-Thorsten 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Christopher Rogers via swift-evolution]

You can shadow self with a guard like you wrote it if use the keyword
escaping backquotes like so:

guard let `self` = self else { return }
On Wed, Jan 6, 2016 at 10:55 AM Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
> strongSelf = self", and 26 occurrences of "self?." (which should arguably
> be changed to the former).
>
> Jacob
>
> On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
> wrote:
>
>> +1.
>>
>> Merely using "self?.something" repeatedly might produce unexpected
>> behavior, if self becomes nil between calls. As I mentioned in another
>> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>>
>> In many cases, I use the pattern
>>
>> somethingAsync { [weak self] in
>> guard let strongSelf = self else { return }
>>
>> // use strongSelf below
>> }
>>
>> But of course, this leads to the unnatural/unwieldy "strongSelf.property"
>> all over the place.
>>
>> I agree with Jordan that "guard let self = self" isn't the most
>> satisfying syntax, but it has the advantage of being a *very* minimal
>> grammar/syntax change, and its behavior is completely clear as long as the
>> user is already familiar with guard.
>>
>> We should also consider whether "self." is required after "guard let self
>> = self". An explicit "guard let self = self" avoids the accidental-capture
>> problem, so I think it's reasonable to allow unqualified property access
>> for the remainder of the scope.
>>
>> Jacob
>>
>> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This has come up before, in a thread called "Proposal: weakStrong self
>>> in completion handler closures". I'm still not 100% happy with the
>>> syntax, but I like that "guard let" can handle non-Void non-Optional
>>> returns well, while 'weakStrong' cannot.
>>>
>>> Jordan
>>>
>>>
>>> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Currently, weakly captured `self` cannot be bound to `guard let …` with
>>> same name, and emits a compiler error.
>>>
>>> class Foo {
>>> func test2(f: ()->()) {
>>> // …
>>> }
>>> func test1() {
>>> test2 { [weak self] in
>>> guard let self = self else { return } // Error.
>>> print(self)
>>> }
>>> }
>>> }
>>>
>>> Do we have any reason to disallow making `self` back to strong
>>> reference? It’d be nice if I can do it. Please consider this case.
>>>
>>> class Foo {
>>> func getValue1() -> Int {
>>> return 1234
>>> }
>>> func test3(value: Int) {
>>> print(value)
>>> }
>>> func test2(f: ()->()) {
>>> // …
>>> }
>>> func test1() {
>>> test2 { [weak self] in
>>> self?.test3(self?.getValue1()) // Doesn't work because it's not
>>> unwrapped.
>>>
>>> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>>>
>>> guard self != nil else { return }
>>> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>>>
>>> guard let self1 = self else { return }
>>> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
>>> new name `self1`.
>>>
>>> guard let self = self else { return }
>>> self.test3(self.getValue1()) // OK.
>>>
>>> }
>>> }
>>> }
>>>
>>> This also can be applied to `if let` or same sort of constructs.
>>>
>>> Even further, we can consider removing required reference to `self`
>>> after `guard let …` if appropriate.
>>>
>>> guard let self = self else { return }
>>> test3(getValue1()) // Referencing to `self` would not be required
>>> anymore. Seems arguable.
>>>
>>> I think this is almost fine because users have to express their
>>> intention explicitly with `guard` statement. If someone erases the `guard`
>>> later, compiler will require explicit self again, and that will prevent
>>> mistakes. But still, I am not sure this removal would be perfectly fine.
>>>
>>> I am not sure whether this is already supported or planned. But lacked
>>> at least in Swift 2.1.1.
>>>
>>> — Hoon H.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

[Brent Royal-Gordon via swift-evolution]

> Taking inspiration from syntax used for methods in classes that override 
> methods in superclasses, require methods that override dynamically dispatched 
> default implementations in protocol extensions to use the override keyword. 
> Likewise, forbid the override keyword if the method being implemented instead 
> 'masks' (would that be the right word?) a statically dispatched method in a 
> protocol extension which can nonetheless be invoked by upcasting to the 
> protocol.

This has been suggested before, usually in the form of a separate `implement` 
keyword. The main problem is that it makes it impossible to write a protocol 
after the fact which formalizes some existing pattern in the types.

What do I mean by that? Well, imagine you need generic access to the `min` and 
`max` static properties of the various integer types. There's no existing 
protocol that includes those members. But you can write one and then extend the 
integer types to conform to your new protocol:

protocol BoundedIntegerType: IntegerType {
static var min: Self { get }
static var max: Self { get }
}
extension Int: BoundedType {}
extension Int8: BoundedType {}
extension Int16: BoundedType {}
extension Int32: BoundedType {}
extension Int64: BoundedType {}

func printLowestPossibleValueOfValue(x: 
Integer) {
print(Integer.min)
}

This only works because `min` and `max` *don't* need any special marking to be 
used to satisfy a requirement. Requiring a keyword like you suggest would 
remove that feature.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Thorsten Seitz via swift-evolution]

+1

Type narrowing would also fit nicely with union types (as demonstrated in 
Ceylon).

-Thorsten 

> Am 05.01.2016 um 23:37 schrieb Dennis Lysenko :
> 
> That said, I am in favor of automatic type narrowing. As long as it doesn't 
> complicate the compiler considerably (if it does, there's little reason to 
> replace optional binding), it's no less confusing than shadowing was when I 
> first saw it, and once you get used to it (shouldn't be more than a day): it 
> is less verbose and perhaps more intuitive (I've found myself reacting to 
> optionals saying "duh, I've already guarded that X is nonnull on this 
> codepath, why would I have to unwrap it again?" in Swift).
> 
>> On Tue, Jan 5, 2016 at 5:35 PM Dennis Lysenko  
>> wrote:
>> Thorsten,
>> 
>> Not that I disapprove (Kotlin does the same and it's great), the precedent 
>> seems to have already been set in people's minds that there won't be any 
>> kind of implicit type narrowing and I predict a fair few will respond with 
>> "You can already do that with optional binding, and I'm uncomfortable seeing 
>> a variable change type in an inner scope" even though shadowing achieves 
>> exactly the same aim. The same happened the last time that type narrowing 
>> was mentioned.
>> 
>> 
>>> On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> Ceylon has type narrowing (not only for optional unwrapping but for type 
>>> checks as well): 
>>> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>>> 
>>> It always struck me as quite natural to do this.
>>> 
>>> -Thorsten
>>> 
 Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution 
 :
 
 
 Whoops, errant button tap.
 
 I've always thought that, 
 
 if let foo = foo? {
 
 }
 
 makes more sense than 
 
 if let foo = foo {
 
 }
 
 as the ? indicates that you are unwrapping the optional and then assigning 
 it to the new variable.
 
 The current syntax must seem incomprehensible/redundant to those new to 
 Swift. This obviously doesn't help with the verbosity at all, but it seems 
 to be more consistent with ? being the operator for unwrapping.
 
 Of course there is also the current optional pattern matching syntax:
 
 if case let foo? = foo {
 
 }
 
 This accomplishes the same thing and is somewhat less perplexing than "if 
 let foo = foo", but must still be baffling to a new user.
 
 You could even have:
 
 if foo? {
 foo.blah()
 }
 
 Which would not create a shadow local variable but would have the same 
 semantics as
 
 foo?.blah()
 
 in that is just providing conditional access to the variable if it's not 
 .None. Not sure if this direct access is desired as it is still magical 
 scoped type manipulation without declaring a new variable.
 
 
 Tyler
 
 
> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier  wrote:
> 
> I've always thought that, 
> 
> if let foo = foo? {
> 
> }
> 
> makes more sense than 
> 
> if let foo = foo {
> 
> }
> 
> as the ? indicates that you are unwrapping the optional and then 
> assigning it to the new variable
> 
>> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution 
>>  wrote:
>> 
>> I’ve only read the last couple of posts but has anybody already 
>> suggested using something like this:
>> 
>> if let foo! {
>>   // code that uses foo
>> }
>> 
>> People already know that the ! is unwrapping a value and that let is 
>> defining a new constant. So why not combine those two?
>> Alternatively it could also be:
>> 
>> if let foo? {
>>   // code that uses foo
>> }
>> 
>> What do you think?
>> 
>> – Cihat
>> 
 Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
 :
 
 
 On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via 
 swift-evolution  wrote:
 
 I was going to suggest something similar (a hard naming problem also):
 
 if has foo {
 // foo is now unwrapped and non-optional
 }
 
 guard has foo else { return }
 
 Does the same thing as `let foo = foo` in practice, but places it in a 
 somewhat different mental model. Instead of unwrapping and immediately 
 assigning to a new constant with the same name (which just looks kind 
 of silly, like some magic voodoo ritual), it sort of asserts that we 
 “have” foo (i.e. it’s not nil), and 

[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Douglas Gregor via swift-evolution]

The review of SE-0009 "Require self for accessing instance members`" ran from 
December 16–20, 2015. The proposal has been rejected.


https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
 


This proposal spawned a massive, polarized discussion with 200+ messages 
involving 80+ participants. We’re thrilled at the enthusiasm and thank all who 
participated. There were many, many interesting points made, along with 
experience reports from various Swift code bases, ideas to help mitigate the 
concerns that motivated the proposal, and so on. Quantitatively, the overall 
community assessment of the proposal was roughly 5:2 against requiring “self.”.

The core team agreed that this proposal is not the right direction for Swift. 
There are a number of reasons for this decision:

* Mandatory “self.” introduces a significant amount of verbosity that does not 
justify itself with added clarity. While it is true that mandatory “self.” may 
prevent a class of bugs, the cost of eliminating those bugs is fairly high in 
terms of visual clutter, which goes against the generally uncluttered feel of 
Swift. Paul Cantrell put it well in his review 

 when he said, “anything that is widely repeated becomes invisible.” Swift aims 
to avoid such boilerplate and repetition in its design, a principle also 
espoused by the Swift API Design Guidelines 
.

* The requirement to use “self.” within potentially-escaping closures is a 
useful indicator of the potential for retain cycles that we don’t want to lose. 
Additionally, developers can optionally use “self.” when they feel it improves 
clarity (e.g., when similar operations are being performed on several different 
instances, of which “self” is one).

* The name-shadowing concerns behind the mandatory “self.” apply equally well 
to anything found by unqualified name lookup, including names found in the 
global scope. To call out members of types as requiring qualification while 
global names do not (even when global names tend to be far more numerous) feels 
inconsistent, but requiring qualification for everything (e.g., “Swift.print”, 
“self.name”) exacerbates the problem of visual clutter. 

* Individuals or teams that feel that explicit “self.” is beneficial for their 
own code bases can enforce such a coding convention via tooling with the status 
quo. If this proposal were accepted, those opposed to the proposal would 
effectively have no recourse because the language itself would be enforcing 
“self.”.

Doug Gregor
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Dennis Lysenko via swift-evolution]

Thorsten,

Not that I disapprove (Kotlin does the same and it's great), the precedent
seems to have already been set in people's minds that there won't be any
kind of implicit type narrowing and I predict a fair few will respond with
"You can already do that with optional binding, and I'm uncomfortable
seeing a variable change type in an inner scope" even though shadowing
achieves exactly the same aim. The same happened the last time that type
narrowing was mentioned.


On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Ceylon has type narrowing (not only for optional unwrapping but for type
> checks as well):
> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>
> It always struck me as quite natural to do this.
>
> -Thorsten
>
> Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution <
> swift-evolution@swift.org>:
>
>
> Whoops, errant button tap.
>
> I've always thought that,
>
> if let foo = foo? {
>
> }
>
> makes more sense than
>
> if let foo = foo {
>
> }
>
> as the ? indicates that you are unwrapping the optional and then assigning
> it to the new variable.
>
> The current syntax must seem incomprehensible/redundant to those new to
> Swift. This obviously doesn't help with the verbosity at all, but it seems
> to be more consistent with ? being the operator for unwrapping.
>
> Of course there is also the current optional pattern matching syntax:
>
> if case let foo? = foo {
>
> }
>
> This accomplishes the same thing and is somewhat less perplexing than "if
> let foo = foo", but must still be baffling to a new user.
>
> You could even have:
>
> if foo? {
> foo.blah()
> }
>
> Which would not create a shadow local variable but would have the same
> semantics as
>
> foo?.blah()
>
> in that is just providing conditional access to the variable if it's not
> .None. Not sure if this direct access is desired as it is still magical
> scoped type manipulation without declaring a new variable.
>
>
> Tyler
>
>
> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier  wrote:
>
> I've always thought that,
>
> if let foo = foo? {
>
> }
>
> makes more sense than
>
> if let foo = foo {
>
> }
>
> as the ? indicates that you are unwrapping the optional and then assigning
> it to the new variable
>
> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve only read the last couple of posts but has anybody already suggested
> using something like this:
>
> if let foo! {
>   // code that uses foo
> }
>
> People already know that the ! is unwrapping a value and that let is
> defining a new constant. So why not combine those two?
> Alternatively it could also be:
>
> if let foo? {
>   // code that uses foo
> }
>
> What do you think?
>
> – Cihat
>
> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution <
> swift-evolution@swift.org>:
>
>
> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was going to suggest something similar (a hard naming problem also):
>
> if has foo {
> // foo is now unwrapped and non-optional
> }
>
> guard has foo else { return }
>
> Does the same thing as `let foo = foo` in practice, but places it in a
> somewhat different mental model. Instead of unwrapping and immediately
> assigning to a new constant with the same name (which just looks kind of
> silly, like some magic voodoo ritual), it sort of asserts that we “have”
> foo (i.e. it’s not nil), and therefore from that point it can just be
> treated as non-optional.
>
> IMHO this, although introduces a new keyword, makes more sense than trying
> to reuse “let” in a context where it seems nonsensical. Perhaps this would
> be closer to Swift’s goals, by reducing very common boilerplate, but
> without harming clarity in a way adding a new meaning to “let” would.
>
> Curious to hear Chris Lattner’s opinion :-)
>
>
> IANACL (I am not a Chris Lattner) but, FWIW, several of us are
> uncomfortable with the idea that a single declared property might have
> different static types in different regions of code.
>
>
> — Radek
>
> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What if we made the keyword "unwrap"?
>
> if unwrap someViewController {
> // now there is a shadowing nonoptional (unwrapped) variable of the same
> name only within this scope, boiling down to simple syntactic sugar for
> optional binding and it is fairly clear.
> }
>
> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> As much fun as it to example with foo, I would argue the opposite when
>> you use some real world variable names:
>>
>> if let someInterestingViewConroller = someInterestingViewConroller {
>> }
>>
>> vs
>>
>> If let someInterestingViewConroller {
>> }
>>
>> We know what let does and it should be 

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Max Howell via swift-evolution]

>> Yes, and indeed, this isn’t really acceptable, but I think any changes to 
>> how this work would involve a discussion on the swift-build-dev mailing 
>> list. Really how targets depend on each other and external dependencies in 
>> the Package.swift manifest needs some work in general.
> 
> Given that you’ve already recognized the future need for more flexible 
> test-module-specific build config, and now there’s also this concern about 
> per-test-module dependencies, is it worth considering giving each test module 
> its own (possibly implicit) target in Package.swift? That might kill several 
> birds with one stone.

I’m not sure it’s worth it yet. You can’t really do anything with targets in 
Package.swift yet (just specify internal inter-module dependencies). I’d rather 
wait until the manifest format had some more functionality and had settled 
more, rather than slap things in without more understanding about how the 
manifest is going to actually be used.

> 3. You propose that “building a module also builds that module's 
> corresponding tests.” Does this apply only to the top-level package, or 
> to all of its dependencies? For example, if my FooApp depends on BarLib, 
> and BarLib’s tests depend on HugeFancyTestFramework, do I have to 
> download and compile HugeFancyTestFramework in order to build FooApp? 
> (Hopefully not!)
 
 HugeFancyTestFramework will not be downloaded or built.
>>> 
>>> That’s a relief!
>> 
>> Probably people would want an option to do this though. You should be 
>> running and checking the tests of your dependencies somewhat regularly.
>> 
>> But when developing your own software, this would be a waste of engineering 
>> time.
> 
> Indeed, clearly that should not be the default. In general, assuming 
> unnecessary building to be “almost free” is a mistake. Carthage’s authors hit 
> this: they built for all platforms by default, stubbornly resisted 
> fine-tuning of the build process at the command line, and then were deluged 
> with complaints as soon as popular libs like Alamofire started building for 
> iOS, OS X, and watchOS even for apps that only needed one of the platforms.
> 

> However, having the option to run dependency tests seems very nice. Something 
> I tentatively like about this proposal is that it nudges library authors to 
> make their tests work immediately on checkout with no further futzing. 
> Running dependency tests would push further in that direction.
> 
> A particular advantage of running all the dependencies’ tests would be to 
> test them against the specific versions of all indirect dependencies used in 
> production. In other words, if MyApp uses FooLib, FooLib depends on BarLib, 
> and FooLib’s author tested against BarLib 1.0 but 1.1 inadvertently 
> introduced a change that breaks FooLib, then running all of MyApp’s 
> dependency tests might catch the breakage.

I agree and I wish we could force all tests to be run. But this is just 
idealism. Practically all of us would just start building with the “don’t do 
that flag”. 

I think at the least when we have a “publish” command we will run all the 
tests. As well as lint. In day to day development we cannot expect developers 
to wait, but we have a duty to ensure the packaging ecosystem we help create is 
as high quality as possible.

Max
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] API Guideline bugs and enhancements

[Rudolf Adamkovič via swift-evolution]

Great discussion, thanks Erika for bringing this up.

Chiming in with a little question here. The API guidelines say:

> Boolean methods and properties should read as assertions about the receiver

I know the document is about APIs but is this also recommended for local 
variables and constants?

Any thoughts?

Thanks!

R+

> On 5 Jan 2016, at 22:57, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> I agree - there are a few I'd love to see discussed.
> 
> I also agree that I appreciate that they are there and so well thought out 
> and presented
> 
> On Jan 5, 2016, at 4:26 PM, Paul Cantrell via swift-evolution 
> > wrote:
> 
>> I’ll second Erica on wanting a place to discuss the API guidelines. In 
>> general, I like their general approach and philosophy — very much so! — but 
>> I also have concerns about some of the details. For example, I totally agree 
>> with Erica’s suggestion that all methods with side effects should be verbs, 
>> not just ones that mutate the receiver.
>> 
>> You can read here a detailed writeup on the sticking points I hit trying to 
>> put the guidelines into practice on a real-world project:
>> 
>> https://gist.github.com/pcantrell/22a6564ca7d22789315b 
>> 
>> 
>> The acceptance rate for Apple-guideline-recommended changes come out at only 
>> about 50%.
>> 
>> I realize that guidelines are just guidelines, but that seems like a bit of 
>> an easy out if the guidelines doc is meant to help unify the style of 
>> disparate Swift libraries.
>> 
>> Cheers,
>> 
>> Paul
>> 
>> 
>>> On Jan 5, 2016, at 2:44 PM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> Are API Design Guideline improvement discussions in scope for the Swift 
>>> Evolution list and if not, where would they go?
>>> 
>>> For example, the current Swift API Design Guidelines follow these rules 
>>> more or less.
>>> Use imperative verb phrases for mutating methods: x.reverse(), x.sort(), 
>>> x.tweak()
>>> Use noun phrases for non-mutating methods: x.distanceTo(...), 
>>> idx.successor()
>>> Seems to me the rules should actually be along the lines of:
>>> Use verb phrases to declare procedural methods, whether or not they mutate 
>>> an instance or just produce side effects: x.reverse(), x.sort(), x.tweak(), 
>>> x.perform(), x.dispatch(), x.send()
>>> Use noun phrases to describe values returned by a functional method: 
>>> x.distanceTo(y), index.successor() (This admittedly leaves further issues 
>>> around other functional methods, for example, seq.separatedBySequence(seq) 
>>> and  int.strideTo(other: Self, step:Self.Stride), etc. )
>>> Are enhancements for API Design Guidelines an area for community 
>>> involvement? Where would you start a discussion about the rules? Would 
>>> modifications involve formal proposals?
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

Thats a small but huge improvement :)

On Tue, Jan 5, 2016 at 6:58 PM, Chris Lattner  wrote:

> You’re completely right, but we don’t need to change the swift language to
> fix that.  As of 3f19714, which I just pushed, we now emit this error
> message (which includes a fixit hint to insert the colon):
>
> t.swift:2:33: error: use [:] to get an empty dictionary literal
> var distanceCache: [Int: Int] = []
> ^
>  :
>
> instead of:
>
> t.swift:2:33: error: contextual type '[Int : Int]' cannot be used with
> array literal
> var distanceCache: [Int: Int] = []
> ^~
>
> That should address the problem, thanks for pointing this out!
>
> -Chris
>
> On Jan 5, 2016, at 4:51 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The problem for me is that is so counter intuitive I didn't even know you
> could do that.
>
> On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira <
> jeremy.j.pere...@googlemail.com> wrote:
>
>> I don’t understand what the problem is
>>
>> > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > See this code:
>> > var distanceCache: [Int: Int] = Dictionary()
>> >
>> > It is very long and tedious to write especially if what I am storing
>> changes.
>> >
>> > I propose we be allowed to do the following:
>> > var distanceCache: [Int: Int] = []
>>
>> You can do
>>
>> var distanceCache: [Int: Int] = [:]
>>
>> Also
>>
>> var distanceCache2 = [Int: Int]()
>>
>>
>> > Perhaps this dictionary syntax is just confusing and it was a bad idea
>> to make it the same as an array. Most languages use "{" so why did swift
>> choose to share "[" with arrays and dictionaries.
>>
>> It’s not the same, you need the colons inside. I imagine that braces were
>> discarded on the grounds that it would confuse the compiler with respect to
>> closures, for example
>>
>> var myClosure = {} // is a variable of type () -> ()
>>
>>
>> >
>> > --
>> >  Wizard
>> > ja...@supmenow.com
>> > +44 7523 279 698
>> >  ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Max Howell via swift-evolution]

> On Jan 5, 2016, at 12:21 PM, Paul Cantrell  wrote:
> 
> Thanks for the clarifications. This helps me understand much better how the 
> proposal plays out.
> 
>> On Jan 5, 2016, at 2:14 PM, Max Howell  wrote:
>> 
>>> 1. The proposal talks in several places about “test modules” (for example, 
>>> “test-module is created per subdirectory of Tests”). How do these test 
>>> modules interact with Package.swift? Does each of them have a separate 
>>> target? If so, how is the test module name specified in the Target(…) entry?
>> 
>> There is no support for referring to test targets in the Package.swift as 
>> part of this proposal.
>> 
>>> 2. Perhaps answered by #1, how does Package.swift specify test-only 
>>> dependencies (e.g. Quick) that are necessary to build tests, but should not 
>>> be exported to downstream projects?
>> 
>> This is already a part of the package manager: 
>> https://github.com/apple/swift-package-manager/pull/74
> 
> Cool. Hadn’t seen the private dependencies yet.
> 
> Taking 1 and 2 together, does that mean that all dependencies necessary for 
> _all_ the test modules must be downloaded & compiled in order to run _any_ or 
> them? Not ideal, but not a deal-killer either

Yes, and indeed, this isn’t really acceptable, but I think any changes to how 
this work would involve a discussion on the swift-build-dev mailing list. 
Really how targets depend on each other and external dependencies in the 
Package.swift manifest needs some work in general.

>>> 3. You propose that “building a module also builds that module's 
>>> corresponding tests.” Does this apply only to the top-level package, or to 
>>> all of its dependencies? For example, if my FooApp depends on BarLib, and 
>>> BarLib’s tests depend on HugeFancyTestFramework, do I have to download and 
>>> compile HugeFancyTestFramework in order to build FooApp? (Hopefully not!)
>> 
>> HugeFancyTestFramework will not be downloaded or built.
> 
> That’s a relief!

Probably people would want an option to do this though. You should be running 
and checking the tests of your dependencies somewhat regularly.

But when developing your own software, this would be a waste of engineering 
time.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

[Vincent Esche via swift-evolution]

Fair point! I’m all in favor of a simple(r) API. Noted, and thanks for the 
comment!

> On 05 Jan 2016, at 03:07, Donnacha Oisín Kidney  
> wrote:
> 
> Unless I’m confused, all of the “ranged” overloads can already be achieved by 
> composing ranged subscripts with the indexOf, etc., methods:
> 
> let ar = [0, 1, 2, 3, 4, 5]
> let ind = ar[3...5].indexOf { n in n % 2 == 0 }
> ar[ind!] // 4
> 
>> On 5 Jan 2016, at 01:00, Vincent Esche via swift-evolution 
>> > wrote:
>> 
>> There are a couple of things I’m not 100% happy with/sure about:
>> 
>> 1.
>> I don’t like how it’s
>> “Of(element:range:)” but 
>> “Of(range:predicate:)”.
>> The reason I went for “Of(range:predicate:)” was to go 
>> with the standard pattern of putting closures last and thus allowing for 
>> trailing closure syntax.
>> 
>> The current order allows for this:
>> “Of(0..10)  { $0.name == “Foobar" }”
>> which I like syntax-wise.
>> It however makes it look like one was looking for a range ("indexOf(0..10, 
>> …)”), not the predicate.
>> 
>> While the alternative requires this:
>> “Of(predicate: { $0.name == “Foobar" }, range: 0..10)”
>> 
>> I’m actually leaning towards the latter now. Dang!
>> 
>> 2.
>> I’m unsure about the name of “lensView”. I first went with “transform”, then 
>> with “mappingFunction”, but found that neither of those made it clear that 
>> the closure should provide a specific view into the element.  Both 
>> “transform" and “mappingFunction” imply the transformation from one data 
>> type to another. It’s not about transforming. It’s about accessing.
>> Thus looked for names of similar patterns and found “keypaths” (kind of) in 
>> ObjC and lenses in Haskell. To people familiar with functional programming 
>> the name should be clear. The closure passed to “lensView” is basically the 
>> getter part of a functional lens.
>> Anyway, I’m not too attached to the name and more than open to suggestions.
>> 
>> 3.
>> “BinarySearchView.init(base:validateAgainst:)” currently asserts. This 
>> should probably be split into two init functions. One assuming the base to 
>> be sorted (“BinarySearchView.init(base:)”, O(1)). And one allowing for a 
>> check, returning nil on failure 
>> (“BinarySearchView.init?(base:validateAgainst:)”, O(self.count)). Or should 
>> at least throw an error, instead of panicking.
>> 
>> Note: I made some minor documentation changes/fixes.
>> See https://gist.github.com/regexident/2b7531bd748f57679671 
>>  for up-to-date 
>> RFC/source code (vs. Markdown-dump at bottom of OP).
>> 
>> - Vincent
>> 
>>> On 04 Jan 2016, at 16:13, Vincent Esche >> > wrote:
>>> 
>>> After having had this code laying around on my Mac since 6/26/15 (waiting 
>>> for Swift to go open source)
>>> I figured it’s about damn time I submit the actual RFC for it. So without 
>>> further ado…
>>> 
>>> One of the areas where Swift’s stdlib is still quite lacking is searching.
>>> Which is a shame as searching (along with indexing) might be among
>>> the most important tasks of computer science/software development.
>>> One might not need fast collection searches for writing a banal fart or 
>>> flashlight app,
>>> but almost every other app is likely to benefit from having a proper 
>>> searching API.
>>> 
>>> So I’d like to fix that.
>>> 
>>> Attached you find a full RFC along with the full and functional source code 
>>> to make it happen.
>>> 
>>> I’d love to hear your opinion on this and will be more than happy to answer 
>>> questions.
>>> 
>>> Rendered Version + Full Implementation: 
>>> https://gist.github.com/regexident/2b7531bd748f57679671 
>>> 
>>> (The code is tested using Quick/Nimble. Tests would thus have to be ported 
>>> to Swift’s XCTest.)
>>> 
>>> - Vincent
>>> 
 Markdown-dump for
 
 # Improved Collection Search
 
 * Proposal: 
 [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
  
 )
 * Author(s): [Vincent Esche](https://github.com/regexident 
 )
 * Status: **Review**
 * Review manager: TBD
 
 ## Introduction
 
 This RFC proposes an extension to the currently rather limited and linear 
 searching API of `CollectionType`, that is `indexOf(element:)` and 
 `indexOf(predicate:)`.
 It proposes the backwards-compatible refactoring of those existing methods 
 as well as the introduction of a view-based ensemble of methods for 
 efficient binary-search.
 
 Swift-evolution thread: [link to the discussion thread for that 
 proposal](https://lists.swift.org/pipermail/swift-evolution 
 

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Andrew Bennett via swift-evolution]

I'm on the fence here, I think it's a good solution if a project has
ongoing objc dependencies.

However I have a few issues/suggestions:

1) If a project is iteratively migrating from objc to swift, as I'm sure
many are (a large project I'm working on included), then it would make that
job much more tedious and increase the objc footprint in the swift code.

2) A linter could help me slowly remove unnecessary side-effects of this
proposal, but it's not ideal, and it does not solve the large amounts of
annotations needed to do so.

3) If this proposal went ahead would existing code be migrated to add the
annotation everywhere? (to retain equivalence)

4) Have you explored any alternatives?
 * instead of defaulting to @objc require an explicit @objc or @nonobjc,
otherwise have a compile-time warning; default to @nonobjc still (for
consistency).
 * @objc(inherit=false)

when put on the protocol it disables what you propose, inherit is true by
default.

 * compile time feedback:
+ An objc compile time warning/error suggesting you add @objc if
there's no matching selector, but there is a swift method.

This may only work in whole module optimisation, also the dynamic nature of
objc may prevent it from being deterministic.

+ A swift compile time warning/error suggesting you add @objc if
there's an objc protocol and an unannotated swift implementation.

If I remember correctly something like this may already exist.




On Tue, Jan 5, 2016 at 4:02 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 4, 2016, at 8:58 PM, John Joyce  wrote:
>
> Would it not be possible to do the relative analog of Objective-C
> nullability macro sandwiches in Swift?
> And then allowing exceptions within the file to be called out explicitly
> with @nonobjc or @objc ?
> @begin_assume_nonobjc
> @end_assume_nonobjc
> @begin_assume_objc
> @begin_assume_objc
>
>
> Ick :)
>
> If we need to annotate several things at once, doing it an extension
> granularity is good enough, because there’s essentially no cost to merging
> or breaking apart extensions as needed.
>
> - Doug
>
> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I like this idea, but I would imagine that for an extension with many
> functions in it, requiring @nonobjc on each one would get tedious very
> fast. Could it be required (or at least allowed in addition to per-method
> annotations) at the extension level?:
> @objc protocol P {}
> @nonobjc extension P {
> func foo() { }
> func bar() { }
> func baz() { }
> func blah() { }
> // etc...
> }
>
> I don’t know if this would have specific implementation ramifications over
> only doing this on each method, if extensions cannot already be modified
> with attributes. I can’t think of a case where I’ve seen annotations added
> to protocol extensions, or any other extensions for that matter.
>
>
> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> We currently have a bit of a surprise when one extends an @objc protocol:
>
> @objc protocol P { }
>
> extension P {
>   func bar() { }
> }
>
> class C : NSObject { }
>
> let c = C()
> print(c.respondsToSelector("bar")) // prints "false"
>
>
> because the members of the extension are not exposed to the Objective-C
> runtime.
>
> There is no direct way to implement Objective-C entry points for protocol
> extensions. One would effectively have to install a category on every
> Objective-C root class [*] with the default implementation or somehow
> intercept all of the operations that might involve that selector.
>
> Alternately, and more simply, we could require @nonobjc on members of
> @objc protocol extensions, as an explicit indicator that the member is not
> exposed to Objective-C. It’ll eliminate surprise and, should we ever find
> both the mechanism and motivation to make default implementations of @objc
> protocol extension members work, we could easily remove the restriction at
> that time.
>
> - Doug
>
> [*] Assuming you can enumerate them, although NSObject and the hidden
> SwiftObject cover the 99%. Even so, that it’s correct either, because the
> root class itself might default such a method, and the category version
> would conflict with it, so...
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Andrey Tarantsov via swift-evolution]

I'm against this, because I often write extensions on Apple classes (like, say, 
UIColor) that are only intended to be used from Swift, in a pure-Swift project, 
and I need no stinking' @nonobjc in there.

How much of a problem can this surprise be? You call a method, the compiler 
tells you it's not there, you look up the reason, no harm done.

A.



> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We currently have a bit of a surprise when one extends an @objc protocol:
> 
> @objc protocol P { }
> 
> extension P {
>   func bar() { }
> }
> 
> class C : NSObject { }
> 
> let c = C()
> print(c.respondsToSelector("bar")) // prints "false"
> 
> because the members of the extension are not exposed to the Objective-C 
> runtime. 
> 
> There is no direct way to implement Objective-C entry points for protocol 
> extensions. One would effectively have to install a category on every 
> Objective-C root class [*] with the default implementation or somehow 
> intercept all of the operations that might involve that selector. 
> 
> Alternately, and more simply, we could require @nonobjc on members of @objc 
> protocol extensions, as an explicit indicator that the member is not exposed 
> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
> mechanism and motivation to make default implementations of @objc protocol 
> extension members work, we could easily remove the restriction at that time.
> 
>   - Doug
> 
> [*] Assuming you can enumerate them, although NSObject and the hidden 
> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
> root class itself might default such a method, and the category version would 
> conflict with it, so...
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Paul Cantrell via swift-evolution]

In principle, having Float, Float32, and Float64 and no “Double” at all seems 
highly sensible to me.

In practice, the migration cost of changing the meaning of Float from “32-bit” 
to “platform preferred size” seems like a potential deal-killer.

P

> On Jan 5, 2016, at 2:25 PM, Alex Johnson via swift-evolution 
>  wrote:
> 
> Just to clarify: I was suggesting removing the name "Double" and giving a 
> different meaning to the name "Float".
> 
> ~ Alex
> 
> On Tue, Jan 5, 2016 at 11:51 AM, Chris Lattner  > wrote:
> 
> These are functionally different cases.  We are *omitting* a C feature by 
> removing ++ and --.  This proposal included keeping the name “Double” but 
> giving it a different meaning.
> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Kevin Wooten via swift-evolution]

>>> That said, personally, my feeling is that the momentum here in the broad 
>>> family of C languages (including things like Java) is very strong, and that 
>>> diverging from that would be extremely problematic.  I don’t see any 
>>> “active" problems with our current names.  If this is a matter of 
>>> aesthetics, or an attempt to align with Ruby/Python/Go instead of C/Java 
>>> etc, then this seems like the wrong direction for Swift.
>> 
>> 
>> Losing alignment to C-like paradigms is a valid concern, but then removing 
>> unwary decrement and increment operators feels out of place... Sad to have 
>> seen it culled.
> 
> These are functionally different cases.  We are *omitting* a C feature by 
> removing ++ and --.  This proposal included keeping the name “Double” but 
> giving it a different meaning.
> 
> There are good and bad parts of C syntax.  The goal is not to cargo cult all 
> of the bad parts of C into Swift, it is to keep the good parts and discard 
> the bad parts.  For things that could go either way, we should keep alignment 
> with C.

All these points are sensible but from a standpoint of my real world experience 
we end up using a typealias for CGFloat in most scenarios because it does 
precisely what we want; that being it tracks natural size.  I presume this is 
also the only reason Apple’s frameworks ever defined it.

I would say, again from my experience, dropping Double and making Float track 
the machine size would be a valid thing to do.  It would also provide a bit of 
synergy with the way Int is handled.  Finally, as far as I know there is no 
“Long” or “LongLong” type in Swift, as there is in C/Java, so some precedent 
has been set to do this as well.

-kw___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Stephen Canon via swift-evolution]

What would this actually gain, other than most floating-point code producing 
different results even for basic arithmetic when run on differing platforms?  
Having “Int” mean “native word size” is tolerable because:

(a) most integer code deals with small numbers for which the result is the same 
either way
(b) if the result were different due to overflow, that would trap in Swift

Neither of these properties holds for floating-point.  1/3 will give one result 
on one platform, and another result on another platform.  Floating-point has 
enough misunderstood sharp edges as is.  We don’t need to add more.

– Steve

> On Jan 5, 2016, at 4:10 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> In principle, having Float, Float32, and Float64 and no “Double” at all seems 
> highly sensible to me.
> 
> In practice, the migration cost of changing the meaning of Float from 
> “32-bit” to “platform preferred size” seems like a potential deal-killer.
> 
> P
> 
>> On Jan 5, 2016, at 2:25 PM, Alex Johnson via swift-evolution 
>> > wrote:
>> 
>> Just to clarify: I was suggesting removing the name "Double" and giving a 
>> different meaning to the name "Float".
>> 
>> ~ Alex
>> 
>> On Tue, Jan 5, 2016 at 11:51 AM, Chris Lattner > > wrote:
>> 
>> These are functionally different cases.  We are *omitting* a C feature by 
>> removing ++ and --.  This proposal included keeping the name “Double” but 
>> giving it a different meaning.
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Paul Cantrell via swift-evolution]

> On Jan 5, 2016, at 2:32 PM, Max Howell  wrote:
> 
>> On Jan 5, 2016, at 12:21 PM, Paul Cantrell  wrote:
>> 
>>> On Jan 5, 2016, at 2:14 PM, Max Howell  wrote:
>>> 
 1. The proposal talks in several places about “test modules” (for example, 
 “test-module is created per subdirectory of Tests”). How do these test 
 modules interact with Package.swift? Does each of them have a separate 
 target? If so, how is the test module name specified in the Target(…) 
 entry?
>>> 
>>> There is no support for referring to test targets in the Package.swift as 
>>> part of this proposal.
>>> 
 2. Perhaps answered by #1, how does Package.swift specify test-only 
 dependencies (e.g. Quick) that are necessary to build tests, but should 
 not be exported to downstream projects?
>>> 
>>> This is already a part of the package manager: 
>>> https://github.com/apple/swift-package-manager/pull/74
>> 
>> Cool. Hadn’t seen the private dependencies yet.
>> 
>> Taking 1 and 2 together, does that mean that all dependencies necessary for 
>> _all_ the test modules must be downloaded & compiled in order to run _any_ 
>> or them? Not ideal, but not a deal-killer either
> 
> Yes, and indeed, this isn’t really acceptable, but I think any changes to how 
> this work would involve a discussion on the swift-build-dev mailing list. 
> Really how targets depend on each other and external dependencies in the 
> Package.swift manifest needs some work in general.

Given that you’ve already recognized the future need for more flexible 
test-module-specific build config, and now there’s also this concern about 
per-test-module dependencies, is it worth considering giving each test module 
its own (possibly implicit) target in Package.swift? That might kill several 
birds with one stone.

(Poor sweet little birdies. Always getting the short end of that idiom.)

 3. You propose that “building a module also builds that module's 
 corresponding tests.” Does this apply only to the top-level package, or to 
 all of its dependencies? For example, if my FooApp depends on BarLib, and 
 BarLib’s tests depend on HugeFancyTestFramework, do I have to download and 
 compile HugeFancyTestFramework in order to build FooApp? (Hopefully not!)
>>> 
>>> HugeFancyTestFramework will not be downloaded or built.
>> 
>> That’s a relief!
> 
> Probably people would want an option to do this though. You should be running 
> and checking the tests of your dependencies somewhat regularly.
> 
> But when developing your own software, this would be a waste of engineering 
> time.

Indeed, clearly that should not be the default. In general, assuming 
unnecessary building to be “almost free” is a mistake. Carthage’s authors hit 
this: they built for all platforms by default, stubbornly resisted fine-tuning 
of the build process at the command line, and then were deluged with complaints 
as soon as popular libs like Alamofire started building for iOS, OS X, and 
watchOS even for apps that only needed one of the platforms.

However, having the option to run dependency tests seems very nice. Something I 
tentatively like about this proposal is that it nudges library authors to make 
their tests work immediately on checkout with no further futzing. Running 
dependency tests would push further in that direction.

A particular advantage of running all the dependencies’ tests would be to test 
them against the specific versions of all indirect dependencies used in 
production. In other words, if MyApp uses FooLib, FooLib depends on BarLib, and 
FooLib’s author tested against BarLib 1.0 but 1.1 inadvertently introduced a 
change that breaks FooLib, then running all of MyApp’s dependency tests might 
catch the breakage.

I realize I’ve wandered from the task at hand. I’ll get a proper review 
together after digesting. Thanks for the clarifications.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[David Owens II via swift-evolution]

Overall, I think the feature is important to have, but I don’t understand some 
of the aspects of the proposal. I also don’t think there is a real focus for 
clarity on the types of testing that are being supported here. The implication 
is that unit tests are what this is being targeted, but is this proposal 
specifically limiting to those particular types of tests? If so, why? If not, 
some of the aspects really don’t make much sense to be defaulted into.

> Additionally we will support directories called FooTests. This layout style 
> is prevalent in existing open source projects and supporting it will minimize 
> vexation for their authors. However in the interest of consistency and the 
> corresponding reduction of cognitive-load when examining new Swift packages 
> we will not  recommend this layout. For example:
> 
> Package
> └── Sources
> │   └── Foo.swift
> └── FooTests
> └── Test.swift

Why support something that that is not going to be recommended? Prevalence of 
something seems like a poor choice, especially when you are going to 
specifically not recommend to use it. Also, the proposal already mentioned an 
override mechanism to allow these to be specified. This seems like something 
that could easily be cut.

> Additionally, we propose that building a module also builds that module's 
> corresponding tests. Although this would result in slightly increased build 
> times, we believe that tests are important enough to justify this (one might 
> even consider slow building tests to be a code smell). We would prefer to go 
> even further by executing the tests each time a module is built as well, but 
> we understand that this would impede debug cycles.

Re-building tests all of the time is a huge time waste. Executing those tests 
even more so (also see original question on the types of tests being 
supported). Not only that, in production software, it’s very often the case 
that there are levels of tests that get run because of the shear amount of them 
that exist and the time involved to run them. In addition to levels, there are 
classifications of tests (perf, robustness, memory, stress, fuzzing, etc…).

This is something that should be an opt-in. The most basic example of this is 
refactoring a code base (which is later briefly mentioned at the end o the 
proposal). The first step is getting the code compiling for the project. It’s 
not true that the very next step you take is fix up the tests, especially in 
the cases that the refactoring/changes are exploratory.

> In the future, we may choose to promote the --test option to be a subcommand 
> of the swift command itself:
> 
> $ swift test
> 
> However, any such decision would warrant extensive design consideration, so 
> as to avoid polluting or crowding the command-line interface. Should there be 
> sufficient demand and justification for it, though, it would be 
> straightforward to add this functionality.


This doesn’t make sense to me. It’s either straightforward, or it requires 
extensive design consideration. I personally strongly dislike coupling the 
notion of building with test execution, so I would much rather see “swift test” 
used, especially with a look into the future where it’s going to be asked for 
the ability to run categories of tests and filter to a particular set of tests 
to be run.

Another real problem with this type of design, is that is makes more advanced 
build systems very complicated to make. For example, distributed builds that 
bring together all of the compiled bits to run tests on get blocked because the 
build command starts to expect certain intermediate output. This is a real 
problem my previous team still has to this day with xcodebuild and actively 
prevents us from doing this exact thing with standard tools from Apple, so we 
have to basically roll our own. I see this design following in the exact same 
footsteps.

I think a lot of the design would be clarified by changing all of “by 
convention” items into realized default values in the Package.swift file. That 
would clearly demonstrate how the work and how we can change them.

-David


> On Jan 5, 2016, at 11:06 AM, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of “Swift Testing” for the Package Manager begins now and runs 
> through Thursday, January 7th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md
> 
> For this particular review, please note that a significant amount of 
> discussion history is available in the original pull request for the proposal:
> 
>   https://github.com/apple/swift-evolution/pull/51
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your 

Re: [swift-evolution] Custom summary for Mirrors?

[Austin Zheng via swift-evolution]

Hi Joe,

I respect the choice of the team to use Custom[Debug]StringConvertible in
lieu of summary. At the same time, in my opinion the output of dump() has
become significantly more difficult to read (c.f. unit tests in
https://github.com/apple/swift/pull/838/files). Would you and the team be
open to exploring alternative solutions that improve the readability of
dump() without increasing API surface area? For example, perhaps the
reflection machinery itself should have special handling for some of the
built-in types. If not, I'll consider this discussion thread complete.

Thanks,
Austin



On Tue, Jan 5, 2016 at 3:22 PM, Jordan Rose  wrote:

> Getting custom summaries for the common CG types certainly seems
> reasonable. We'd have to get approval from the appropriate teams at Apple,
> but I can't see any objections.
>
> Jordan
>
>
> On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I believe 'summary' is obsolete, and you're supposed to use
> Custom[Debug]StringConvertible to customize your type's reporting now.
>
> -Joe
>
> On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I'd like to gauge reaction for a proposal I was considering: adding to the
> standard library's Mirror type a 'summary' property, and the option to
> initialize a Mirror with a custom summary. If no custom summary is
> provided, the summary would default to the string produced by calling
> String(reflecting: subject) on the subject at the time of mirror creation.
>
> Some context: right now, there are two APIs for mirrors in the standard
> library: CustomReflectable, which is publicly exposed and relies on the
> conforming type creating a Mirror object, and _Reflectable, which relies on
> the conforming type having a companion type conforming to _MirrorType. A
> short-term goal is to migrate the standard library's types off the
> _Reflectable API and have them use the CustomReflectable API, and changing
> dump() accordingly.
>
> The extant implementation of dump() uses a property on _MirrorType called
> "summary". (This is where e.g. "4 elements" comes from when you dump() an
> array.) "summary" is absent from Mirror or any types related to
> CustomReflectable. I asked Joe Groff about this and the rationale was that
> it was deemed too similar to debugDescription (or String(reflecting: foo))
> to be worth carrying over.
>
> I would like to suggest that there might be a purpose for "summary":
>
> - Types with children, especially container types like arrays, often print
> out a description of their children as part of their debugDescription or
> description, redundant when using an API like dump() which provides a
> structural representation of the children of the subject. In such cases a
> lighter-weight description (like "3 elements") might be more appropriate to
> represent to the user.
>
> - Certain types like CGRect don't conform to CustomStringConvertible,
> CustomDebugStringConvertible, Streamable, etc. Having a custom summary for
> these types customized by the corresponding Mirror would allow for a
> 'pretty' representation during reflection in lieu of the ugly one generated
> by the runtime without making more substantial changes to the API which
> might break third-party code (such as conforming CGRect to any of the
> aforementioned protocols).
>
> I know that Mirror (and reflection as a whole) are being considered for
> major design changes, so this would be a minor transient change to make the
> API easier to work with in the meantime.
>
> Please let me know whether or not you think this proposed change is
> meaningful and worthwhile, or if you have any questions.
>
> Best,
> Austin
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Custom summary for Mirrors?

[Dave Abrahams via swift-evolution]

> On Jan 5, 2016, at 5:28 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hi Joe,
> 
> I respect the choice of the team to use Custom[Debug]StringConvertible in 
> lieu of summary. At the same time, in my opinion the output of dump() has 
> become significantly more difficult to read (c.f. unit tests in 
> https://github.com/apple/swift/pull/838/files 
> ).

Specific examples of readability regressions, please?

> Would you and the team be open to exploring alternative solutions that 
> improve the readability of dump() without increasing API surface area?

Sure.

> For example, perhaps the reflection machinery itself should have special 
> handling for some of the built-in types. If not, I'll consider this 
> discussion thread complete.
> 
> Thanks,
> Austin
> 
> 
> 
> On Tue, Jan 5, 2016 at 3:22 PM, Jordan Rose  > wrote:
> Getting custom summaries for the common CG types certainly seems reasonable. 
> We'd have to get approval from the appropriate teams at Apple, but I can't 
> see any objections.
> 
> Jordan
> 
> 
>> On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> I believe 'summary' is obsolete, and you're supposed to use 
>> Custom[Debug]StringConvertible to customize your type's reporting now.
>> 
>> -Joe
>> 
>>> On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution 
>>> > wrote:
>>> 
>>> Hi all,
>>> 
>>> I'd like to gauge reaction for a proposal I was considering: adding to the 
>>> standard library's Mirror type a 'summary' property, and the option to 
>>> initialize a Mirror with a custom summary. If no custom summary is 
>>> provided, the summary would default to the string produced by calling 
>>> String(reflecting: subject) on the subject at the time of mirror creation.
>>> 
>>> Some context: right now, there are two APIs for mirrors in the standard 
>>> library: CustomReflectable, which is publicly exposed and relies on the 
>>> conforming type creating a Mirror object, and _Reflectable, which relies on 
>>> the conforming type having a companion type conforming to _MirrorType. A 
>>> short-term goal is to migrate the standard library's types off the 
>>> _Reflectable API and have them use the CustomReflectable API, and changing 
>>> dump() accordingly.
>>> 
>>> The extant implementation of dump() uses a property on _MirrorType called 
>>> "summary". (This is where e.g. "4 elements" comes from when you dump() an 
>>> array.) "summary" is absent from Mirror or any types related to 
>>> CustomReflectable. I asked Joe Groff about this and the rationale was that 
>>> it was deemed too similar to debugDescription (or String(reflecting: foo)) 
>>> to be worth carrying over.
>>> 
>>> I would like to suggest that there might be a purpose for "summary":
>>> 
>>> - Types with children, especially container types like arrays, often print 
>>> out a description of their children as part of their debugDescription or 
>>> description, redundant when using an API like dump() which provides a 
>>> structural representation of the children of the subject. In such cases a 
>>> lighter-weight description (like "3 elements") might be more appropriate to 
>>> represent to the user.
>>> 
>>> - Certain types like CGRect don't conform to CustomStringConvertible, 
>>> CustomDebugStringConvertible, Streamable, etc. Having a custom summary for 
>>> these types customized by the corresponding Mirror would allow for a 
>>> 'pretty' representation during reflection in lieu of the ugly one generated 
>>> by the runtime without making more substantial changes to the API which 
>>> might break third-party code (such as conforming CGRect to any of the 
>>> aforementioned protocols).
>>> 
>>> I know that Mirror (and reflection as a whole) are being considered for 
>>> major design changes, so this would be a minor transient change to make the 
>>> API easier to work with in the meantime.
>>> 
>>> Please let me know whether or not you think this proposed change is 
>>> meaningful and worthwhile, or if you have any questions.
>>> 
>>> Best,
>>> Austin
>>>  ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 

Re: [swift-evolution] Beef up Imports

[Simon Pilkington via swift-evolution]

I like the fact that this would retain simplicity for basic uses - developers 
could continue to use 'import Mod' and not even know about the more advanced 
syntax unless they need that power. The additional syntax seems like a natural 
progression from the base case.

Kevin, I understand the motivation for not really needed renaming for qualified 
imports but it feels like we would still need them for unqualified/global ones. 
 Do you think this is a valid use case? As suggested previously I think this 
would be least confusing/ambiguous by using a seperate renaming syntax -
import Mod hiding (x,y) renaming (z as zz)

An import statement such as above could equally be handled by seperate imports 
- one for hiding and one for renaming - and it might be worth being flexible 
and support both styles.

+1 to submodules as well, particularly if integrated into SPM to help 
optimise/reduce compile times when a module depends only on part of an 
otherwise related group of functionality that should be 
vended/consumed/versioned together.

-Simon

> On 29 Dec 2015, at 11:47 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> I like the idea here, but I'm not sold on the syntax. I also do explicitly 
> want an `import qualified`. And with qualified imports, I question whether we 
> really need to support renaming in the import syntax here.
>  
> I'm tempted to say we should just crib Haskell's import rules 
> (https://wiki.haskell.org/Import ), with the 
> minor change that importing members by name still makes them accessible via 
> the module name too (in Haskell `import Mod (x, y)` makes `x` and `y` visible 
> but does not make `Mod.x` or `Mod.y` visible). This lets you say things like
>  
> import Mod // imports Mod and all its members
> import Mod () // only provides access to protocol conformances declared in 
> Mod, doesn't actually import anything
> import Mod (x,y) // imports `x` and `y`, which are also accessible as e.g. 
> `Mod.x`, but does not provide `z` or `Mod.z`
> import qualified Mod // imports Mod but all access to members has to go 
> through it, e.g. `Mod.x`
> import qualified Mod (x,y) // imports Mod but only provides access to `Mod.x` 
> and `Mod.y` but not e.g. `Mod.z`
> import Mod hiding (x,y) // imports Mod and its members except for `x` or `y`
> import qualified Mod hiding (x,y) // imports e.g. `Mod.z` but not `Mod.x` or 
> `Mod.y`
> import Mod as Foo // imports Mod and renames the module to Foo, so e.g. `x` 
> and `Foo.x` are accessible
> import Mod as Foo (x,y) // renames Mod to Foo, provides `x`, `y`, `Foo.x`, 
> and `Foo.y`
> import qualified Mod as Foo // renames Mod to Foo, all members are accessible 
> via the module e.g. `Foo.x`
> import qualified Mod as Foo (x,y) // renames Mod to Foo, provides access to 
> `Foo.x` and `Foo.y` but not e.g. `Foo.z`
>  
> Furthermore, you can have multiple import statements from the same module, so 
> you can say something like
>  
> import qualified Mod
> import Mod (x,y)
>  
> to provide access to all of Mod qualified with the name, and additionally 
> import `x` and `y` as unqualified identifiers.
>  
> -Kevin Ballard
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Jordan Rose via swift-evolution]

This has come up before, in a thread called "Proposal: weakStrong self in 
completion handler closures". I'm still not 100% happy with the syntax, but I 
like that "guard let" can handle non-Void non-Optional returns well, while 
'weakStrong' cannot.

Jordan


> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution 
>  wrote:
> 
> Currently, weakly captured `self` cannot be bound to `guard let …` with same 
> name, and emits a compiler error.
> 
>   class Foo {
>   func test2(f: ()->()) {
>   // … 
>   }
>   func test1() {
>   test2 { [weak self] in
>   guard let self = self else { return } // Error.
>   print(self)
>   }
>   }
>   }
> 
> Do we have any reason to disallow making `self` back to strong reference? 
> It’d be nice if I can do it. Please consider this case.
> 
>   class Foo {
>   func getValue1() -> Int {
>   return 1234
>   }
>   func test3(value: Int) {
>   print(value)
>   }
>   func test2(f: ()->()) {
>   // … 
>   }
>   func test1() {
>   test2 { [weak self] in
>   self?.test3(self?.getValue1()) // Doesn't work 
> because it's not unwrapped.
> 
>   self!.test3(self!.getValue1()) // Considered 
> harmful due to `!`.
> 
>   guard self != nil else { return }
>   self!.test3(self!.getValue1()) // OK, but still 
> looks and feels harmful.
> 
>   guard let self1 = self else { return }
>   self1.test3(self1.getValue1()) // OK, but feels 
> ugly due to unnecessary new name `self1`.
> 
>   guard let self = self else { return }
>   self.test3(self.getValue1()) // OK.
> 
>   }
>   }
>   }
> 
> This also can be applied to `if let` or same sort of constructs.
> 
> Even further, we can consider removing required reference to `self` after 
> `guard let …` if appropriate.
> 
>   guard let self = self else { return } 
>   test3(getValue1()) // Referencing to `self` would not be required 
> anymore. Seems arguable.
> 
> I think this is almost fine because users have to express their intention 
> explicitly with `guard` statement. If someone erases the `guard` later, 
> compiler will require explicit self again, and that will prevent mistakes. 
> But still, I am not sure this removal would be perfectly fine.
> 
> I am not sure whether this is already supported or planned. But lacked at 
> least in Swift 2.1.1.
> 
> — Hoon H.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Tue, Jan 5, 2016, at 03:43 PM, Jordan Rose wrote:
>
>> On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution > evolut...@swift.org> wrote:
>>
>>>
>>> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:
> `buffered` is no more problematic than `lazy` is. In fact, calling
> `buffered` actually doesn't have any side-effects at all (it can
> avoid fetching the first element until you call `first` on the
> result of `buffered`).

 If `seq` is a single-pass sequence, then `seq.buffered.first` will
 consume an element from `seq`, even though you only accessed two
 properties. That's why I call it problematic.

 (If calling `buffered` somehow rendered the original sequence
 unusable—for instance, if we had some way to express that the
 `BufferedSequence` takes unique ownership of its base—this wouldn't
 bother me as much.)
>>>
>>> If `sequence` is a single-pass sequence, wrapping it in any other
>>> sequence type and then doing anything with that other sequence type
>>> makes the original sequence unusable (or rather, you can still use
>>> it but the elements yielded from any further access to the original
>>> sequence can be completely arbitrary).
>>>
>>> And for the record we already have precedent for the specific case
>>> of `seq.prop1.prop2` destructively consuming the original sequence:
>>> `seq.lazy.array`.
>>
>> Yes, and there are arguments for dropping “.array” as a property.
>> The convention is that “conversions” (ill-defined, I know) use
>> constructor syntax, and we are currently heading towards the
>> elimination of "convenience” interfaces that duplicate functionality,
>> so we might end up with Array(seq).
>>
>> All that said, single-pass Sequences are just weird in that they get
>> mutated without calling any mutating methods on them; you mutate them
>> by calling a mutating method on a separate generator instance.  In
>> other words, they fundamentally have reference semantics. There may
>> be some better way to address this whole area, but we’ll have to go
>> much deeper than merely poking at the question of a `.first`
>> property.
>
> Should "generate()" be a mutating method on SequenceType, then? And a
> non-mutating one on CollectionType, obviously.

No, that would make SequenceType too hard to use. Specific sequences
could still have non-mutating generate() methods, but any kind of
generic Sequence wrapper would be forced to use a mutating generate(),
and that would make the ergonomics of using them awful. For example,
instead of

for x in seq.lazy.map(f) { ... }

you'd have to say

var seq2 = seq.lazy.map(f)    for x in seq { ... }

And in the end, it wouldn't really solve anything anyway, because you
can still implement single-pass sequences using a non-mutating
generate() anyway (either the sequence is a class, or it uses a class or
UnsafeMutablePointer internally, or it manipulates global state, e.g. a
sequence that reads lines from stdin with readLine()).

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add public(objc) modifier

[Kevin Ballard via swift-evolution]

Code completion aside, it just makes me really unhappy to expose a Swift
API that nobody should *ever* call from Swift. I just don't want to have
that API be accessible at all when it only exists to serve as the Obj-C
entrypoint.

-Kevin Ballard

On Tue, Jan 5, 2016, at 02:55 PM, Félix Cloutier wrote:
> .NET has an EditorBrowsable[1] attribute that controls whether things
> appear in autocomplete or not. I think that this alternative deserves
> some consideration.
>
> It clearly won't have identical semantics, but I think that it would
> be a little more graceful and much less involved. This solution only
> needs a new attribute and SourceKit changes.
>
> Félix
>
>> Le 5 janv. 2016 à 15:23:55, Kevin Ballard via swift-evolution > evolut...@swift.org> a écrit :
>>
>> Proposal PR submitted as
>> https://github.com/apple/swift-evolution/pull/85
>>
>> -Kevin Ballard
>>
>> On Tue, Dec 15, 2015, at 11:18 AM, Kevin Ballard wrote:
>>> When writing ObjC code, there's a macro NS_REFINED_FOR_SWIFT (or
>>> __attribute__((swift_private))) that mangles the name when imported
>>> into Swift. The intention here is to hide an API from normal Swift
>>> usage (but still make it callable) so that a better Swift API can be
>>> written around it.
>>>
>>> But there's no facility for doing this in reverse. You can expose
>>> Swift APIs to ObjC, but the API has to be ObjC-compatible. Which
>>> means that if you have a non-ObjC-compatible API, you have to write
>>> a separate API to expose it to ObjC, and this separate API now shows
>>> up in the Swift API too.
>>>
>>> I think the simplest way to fix this is to allow for a modifier
>>> public(objc) (following the syntax of private(set)). The only thing
>>> this modifier does is ensure the declaration gets added to the
>>> generated header as if it were public (or—for apps—internal). If the
>>> declaration is not marked as @objc then it would emit an error (it
>>> could imply @objc but it feels weird to me to have an access control
>>> modifier do that). If the declaration is already public (but not
>>> internal, so the same source can be used in apps and libraries) it
>>> will emit a warning.
>>>
>>> Armed with this new modifier, I can start to write code like
>>>
>>> class MyClass: NSObject {    func foo(x: T) { ... } }
>>>
>>> extension MyClass {    @objc(foo) public(objc) private func __foo(x:
>>> AnyObject) { ... } }
>>>
>>> When used on a property that already has private(set), the
>>> public(objc) modifier will only apply to the getter (e.g. the
>>> private(set) takes precedence for the setter).
>>>
>>> Alternatives:
>>>
>>> * Add a new attribute @export_objc that has the same behavior.
>>>
>>> * Change the @objc attribute to take an optional second argument,
>>>   which may be the token "exported", as in @objc(foo,exported). When
>>>   using the "exported" token, the selector portion is required. We
>>>   could possibly support an empty selector to indicate the default,
>>>   as in @objc(,exported), but that looks odd.
>>>
>>> My preference is for public(objc) as proposed as it matches more
>>> closely with the intended behavior, which is "this API is private in
>>> Swift and public in ObjC".
>>>
>>> -Kevin Ballard
>> ___
>> swift-evolution mailing list swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution



Links:

  1. 
https://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute(v=vs.110).aspx
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Custom summary for Mirrors?

[Jordan Rose via swift-evolution]

Getting custom summaries for the common CG types certainly seems reasonable. 
We'd have to get approval from the appropriate teams at Apple, but I can't see 
any objections.

Jordan


> On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution 
>  wrote:
> 
> I believe 'summary' is obsolete, and you're supposed to use 
> Custom[Debug]StringConvertible to customize your type's reporting now.
> 
> -Joe
> 
>> On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> I'd like to gauge reaction for a proposal I was considering: adding to the 
>> standard library's Mirror type a 'summary' property, and the option to 
>> initialize a Mirror with a custom summary. If no custom summary is provided, 
>> the summary would default to the string produced by calling 
>> String(reflecting: subject) on the subject at the time of mirror creation.
>> 
>> Some context: right now, there are two APIs for mirrors in the standard 
>> library: CustomReflectable, which is publicly exposed and relies on the 
>> conforming type creating a Mirror object, and _Reflectable, which relies on 
>> the conforming type having a companion type conforming to _MirrorType. A 
>> short-term goal is to migrate the standard library's types off the 
>> _Reflectable API and have them use the CustomReflectable API, and changing 
>> dump() accordingly.
>> 
>> The extant implementation of dump() uses a property on _MirrorType called 
>> "summary". (This is where e.g. "4 elements" comes from when you dump() an 
>> array.) "summary" is absent from Mirror or any types related to 
>> CustomReflectable. I asked Joe Groff about this and the rationale was that 
>> it was deemed too similar to debugDescription (or String(reflecting: foo)) 
>> to be worth carrying over.
>> 
>> I would like to suggest that there might be a purpose for "summary":
>> 
>> - Types with children, especially container types like arrays, often print 
>> out a description of their children as part of their debugDescription or 
>> description, redundant when using an API like dump() which provides a 
>> structural representation of the children of the subject. In such cases a 
>> lighter-weight description (like "3 elements") might be more appropriate to 
>> represent to the user.
>> 
>> - Certain types like CGRect don't conform to CustomStringConvertible, 
>> CustomDebugStringConvertible, Streamable, etc. Having a custom summary for 
>> these types customized by the corresponding Mirror would allow for a 
>> 'pretty' representation during reflection in lieu of the ugly one generated 
>> by the runtime without making more substantial changes to the API which 
>> might break third-party code (such as conforming CGRect to any of the 
>> aforementioned protocols).
>> 
>> I know that Mirror (and reflection as a whole) are being considered for 
>> major design changes, so this would be a minor transient change to make the 
>> API easier to work with in the meantime.
>> 
>> Please let me know whether or not you think this proposed change is 
>> meaningful and worthwhile, or if you have any questions.
>> 
>> Best,
>> Austin
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Beef up Imports

[Jordan Rose via swift-evolution]

I'm (personally) not such a fan of saying "import just this one thing" or 
"import everything except this one thing"—you end up trying to use 
UIImage(named:), and then realizing you haven't imported any of the top-level 
names. But "import qualified" seems great to me, and "import Foo as Bar" also 
seems reasonable.

Jordan


> On Dec 28, 2015, at 16:47, Kevin Ballard via swift-evolution 
>  wrote:
> 
> I like the idea here, but I'm not sold on the syntax. I also do explicitly 
> want an `import qualified`. And with qualified imports, I question whether we 
> really need to support renaming in the import syntax here.
>  
> I'm tempted to say we should just crib Haskell's import rules 
> (https://wiki.haskell.org/Import ), with the 
> minor change that importing members by name still makes them accessible via 
> the module name too (in Haskell `import Mod (x, y)` makes `x` and `y` visible 
> but does not make `Mod.x` or `Mod.y` visible). This lets you say things like
>  
> import Mod // imports Mod and all its members
> import Mod () // only provides access to protocol conformances declared in 
> Mod, doesn't actually import anything
> import Mod (x,y) // imports `x` and `y`, which are also accessible as e.g. 
> `Mod.x`, but does not provide `z` or `Mod.z`
> import qualified Mod // imports Mod but all access to members has to go 
> through it, e.g. `Mod.x`
> import qualified Mod (x,y) // imports Mod but only provides access to `Mod.x` 
> and `Mod.y` but not e.g. `Mod.z`
> import Mod hiding (x,y) // imports Mod and its members except for `x` or `y`
> import qualified Mod hiding (x,y) // imports e.g. `Mod.z` but not `Mod.x` or 
> `Mod.y`
> import Mod as Foo // imports Mod and renames the module to Foo, so e.g. `x` 
> and `Foo.x` are accessible
> import Mod as Foo (x,y) // renames Mod to Foo, provides `x`, `y`, `Foo.x`, 
> and `Foo.y`
> import qualified Mod as Foo // renames Mod to Foo, all members are accessible 
> via the module e.g. `Foo.x`
> import qualified Mod as Foo (x,y) // renames Mod to Foo, provides access to 
> `Foo.x` and `Foo.y` but not e.g. `Foo.z`
>  
> Furthermore, you can have multiple import statements from the same module, so 
> you can say something like
>  
> import qualified Mod
> import Mod (x,y)
>  
> to provide access to all of Mod qualified with the name, and additionally 
> import `x` and `y` as unqualified identifiers.
>  
> -Kevin Ballard
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add SequenceType.first

[Jordan Rose via swift-evolution]

> On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution 
>>  wrote:
>> 
>> On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:
 `buffered` is no more problematic than `lazy` is. In fact, calling 
 `buffered` actually doesn't have any side-effects at all (it can avoid 
 fetching the first element until you call `first` on the result of 
 `buffered`).
>>> 
>>> If `seq` is a single-pass sequence, then `seq.buffered.first` will consume 
>>> an element from `seq`, even though you only accessed two properties. That's 
>>> why I call it problematic.
>>> 
>>> (If calling `buffered` somehow rendered the original sequence unusable—for 
>>> instance, if we had some way to express that the `BufferedSequence` takes 
>>> unique ownership of its base—this wouldn't bother me as much.)
>> 
>> If `sequence` is a single-pass sequence, wrapping it in any other sequence 
>> type and then doing anything with that other sequence type makes the 
>> original sequence unusable (or rather, you can still use it but the elements 
>> yielded from any further access to the original sequence can be completely 
>> arbitrary).
>> 
>> And for the record we already have precedent for the specific case of 
>> `seq.prop1.prop2` destructively consuming the original sequence: 
>> `seq.lazy.array`.
> 
> Yes, and there are arguments for dropping “.array” as a property.  The 
> convention is that “conversions” (ill-defined, I know) use constructor 
> syntax, and we are currently heading towards the elimination of "convenience” 
> interfaces that duplicate functionality, so we might end up with Array(seq).  
> 
> All that said, single-pass Sequences are just weird in that they get mutated 
> without calling any mutating methods on them; you mutate them by calling a 
> mutating method on a separate generator instance.  In other words, they 
> fundamentally have reference semantics. There may be some better way to 
> address this whole area, but we’ll have to go much deeper than merely poking 
> at the question of a `.first` property. 

Should "generate()" be a mutating method on SequenceType, then? And a 
non-mutating one on CollectionType, obviously.

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

[Paul Cantrell via swift-evolution]

> On Jan 5, 2016, at 4:48 PM, Max Howell  wrote:
> 
>>> Yes, and indeed, this isn’t really acceptable, but I think any changes to 
>>> how this work would involve a discussion on the swift-build-dev mailing 
>>> list. Really how targets depend on each other and external dependencies in 
>>> the Package.swift manifest needs some work in general.
>> 
>> Given that you’ve already recognized the future need for more flexible 
>> test-module-specific build config, and now there’s also this concern about 
>> per-test-module dependencies, is it worth considering giving each test 
>> module its own (possibly implicit) target in Package.swift? That might kill 
>> several birds with one stone.
> 
> I’m not sure it’s worth it yet. You can’t really do anything with targets in 
> Package.swift yet (just specify internal inter-module dependencies). I’d 
> rather wait until the manifest format had some more functionality and had 
> settled more, rather than slap things in without more understanding about how 
> the manifest is going to actually be used.

Fair enough. I’d at least make sure that this proposal doesn’t interfere with 
doing that in the future.

(My understanding of the package manager is too shallow to make that assessment 
myself, so I’ll just leave the thought sitting there….)

>>> You should be running and checking the tests of your dependencies somewhat 
>>> regularly.
>>> 
>>> But when developing your own software, this would be a waste of engineering 
>>> time.
>> 
>> Indeed, clearly that should not be the default. In general, assuming 
>> unnecessary building to be “almost free” is a mistake.
>> …
>> However, having the option to run dependency tests seems very nice.
> 
> I agree and I wish we could force all tests to be run. But this is just 
> idealism. Practically all of us would just start building with the “don’t do 
> that flag”. 
> 
> I think at the least when we have a “publish” command we will run all the 
> tests. As well as lint. In day to day development we cannot expect developers 
> to wait, but we have a duty to ensure the packaging ecosystem we help create 
> is as high quality as possible.

Yes, anything that slows or complicates the dev cycle will send everyone 
straight to “torches and pitchforks” mode, and will be the target of hacks and 
workarounds galore. The normal build cycle needs to be as lean as possible.

Running dependency tests by default for any sort of “publish” command seems 
right.

Now lint … lint I’m not sure about. It’s problematic as soon as you try to 
establish a standard, as we’ve already established on this list in the 
“mandatory self” discussion. The truth is that I don’t care about a third party 
lib’s weird formatting decisions nearly as much as I care about its tests 
passing.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

Perhaps instead of "auto" we could allow "lazy" to create a default lazy
constructor for these cases ?

On Tue, Jan 5, 2016 at 12:39 PM, James Campbell  wrote:

> See this code:
>
> var distanceCache: [Int: Int] = Dictionary()
> It is very long and tedious to write especially if what I am storing
> changes.
>
> I propose we be allowed to do the following:
>
> *var distanceCache: [Int: Int] = []*
>
> If this isn't possible then I wouldn't mind having some way of telling the
> compiler to auto create it like so:
>
> *var distanceCache: [Int: Int] ()*
>
> or
>
> *var distanceCache: [Int: Int] = new Dictionary*
>
> or even:
>
> *var distanceCache: [Int: Int] = auto*
>
> *auto var distanceCache: [Int: Int]*
>
> (auto short for auto create)
>
>
> Perhaps this dictionary syntax is just confusing and it was a bad idea to
> make it the same as an array. Most languages use "{" so why did swift
> choose to share "[" with arrays and dictionaries.
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[Jeremy Pereira via swift-evolution]

I don’t understand what the problem is

> On 5 Jan 2016, at 12:39, James Campbell via swift-evolution 
>  wrote:
> 
> See this code:
> var distanceCache: [Int: Int] = Dictionary()
> 
> It is very long and tedious to write especially if what I am storing changes.
> 
> I propose we be allowed to do the following:
> var distanceCache: [Int: Int] = []

You can do 

var distanceCache: [Int: Int] = [:]

Also

var distanceCache2 = [Int: Int]()


> Perhaps this dictionary syntax is just confusing and it was a bad idea to 
> make it the same as an array. Most languages use "{" so why did swift choose 
> to share "[" with arrays and dictionaries.

It’s not the same, you need the colons inside. I imagine that braces were 
discarded on the grounds that it would confuse the compiler with respect to 
closures, for example

var myClosure = {} // is a variable of type () -> ()


> 
> -- 
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

See this code:

var distanceCache: [Int: Int] = Dictionary()
It is very long and tedious to write especially if what I am storing
changes.

I propose we be allowed to do the following:

*var distanceCache: [Int: Int] = []*

If this isn't possible then I wouldn't mind having some way of telling the
compiler to auto create it like so:

*var distanceCache: [Int: Int] ()*

or

*var distanceCache: [Int: Int] = new Dictionary*

or even:

*var distanceCache: [Int: Int] = auto*

*auto var distanceCache: [Int: Int]*

(auto short for auto create)


Perhaps this dictionary syntax is just confusing and it was a bad idea to
make it the same as an array. Most languages use "{" so why did swift
choose to share "[" with arrays and dictionaries.
-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

The problem for me is that is so counter intuitive I didn't even know you
could do that.

On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira <
jeremy.j.pere...@googlemail.com> wrote:

> I don’t understand what the problem is
>
> > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > See this code:
> > var distanceCache: [Int: Int] = Dictionary()
> >
> > It is very long and tedious to write especially if what I am storing
> changes.
> >
> > I propose we be allowed to do the following:
> > var distanceCache: [Int: Int] = []
>
> You can do
>
> var distanceCache: [Int: Int] = [:]
>
> Also
>
> var distanceCache2 = [Int: Int]()
>
>
> > Perhaps this dictionary syntax is just confusing and it was a bad idea
> to make it the same as an array. Most languages use "{" so why did swift
> choose to share "[" with arrays and dictionaries.
>
> It’s not the same, you need the colons inside. I imagine that braces were
> discarded on the grounds that it would confuse the compiler with respect to
> closures, for example
>
> var myClosure = {} // is a variable of type () -> ()
>
>
> >
> > --
> >  Wizard
> > ja...@supmenow.com
> > +44 7523 279 698
> >  ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Jacob Bandes-Storch via swift-evolution]

+1.

Merely using "self?.something" repeatedly might produce unexpected
behavior, if self becomes nil between calls. As I mentioned in another
thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).

In many cases, I use the pattern

somethingAsync { [weak self] in
guard let strongSelf = self else { return }

// use strongSelf below
}

But of course, this leads to the unnatural/unwieldy "strongSelf.property"
all over the place.

I agree with Jordan that "guard let self = self" isn't the most satisfying
syntax, but it has the advantage of being a *very* minimal grammar/syntax
change, and its behavior is completely clear as long as the user is already
familiar with guard.

We should also consider whether "self." is required after "guard let self =
self". An explicit "guard let self = self" avoids the accidental-capture
problem, so I think it's reasonable to allow unqualified property access
for the remainder of the scope.

Jacob

On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> This has come up before, in a thread called "Proposal: weakStrong self in
> completion handler closures". I'm still not 100% happy with the syntax,
> but I like that "guard let" can handle non-Void non-Optional returns well,
> while 'weakStrong' cannot.
>
> Jordan
>
>
> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Currently, weakly captured `self` cannot be bound to `guard let …` with
> same name, and emits a compiler error.
>
> class Foo {
> func test2(f: ()->()) {
> // …
> }
> func test1() {
> test2 { [weak self] in
> guard let self = self else { return } // Error.
> print(self)
> }
> }
> }
>
> Do we have any reason to disallow making `self` back to strong reference?
> It’d be nice if I can do it. Please consider this case.
>
> class Foo {
> func getValue1() -> Int {
> return 1234
> }
> func test3(value: Int) {
> print(value)
> }
> func test2(f: ()->()) {
> // …
> }
> func test1() {
> test2 { [weak self] in
> self?.test3(self?.getValue1()) // Doesn't work because it's not unwrapped.
>
> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>
> guard self != nil else { return }
> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>
> guard let self1 = self else { return }
> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
> new name `self1`.
>
> guard let self = self else { return }
> self.test3(self.getValue1()) // OK.
>
> }
> }
> }
>
> This also can be applied to `if let` or same sort of constructs.
>
> Even further, we can consider removing required reference to `self` after
> `guard let …` if appropriate.
>
> guard let self = self else { return }
> test3(getValue1()) // Referencing to `self` would not be required anymore.
> Seems arguable.
>
> I think this is almost fine because users have to express their intention
> explicitly with `guard` statement. If someone erases the `guard` later,
> compiler will require explicit self again, and that will prevent mistakes.
> But still, I am not sure this removal would be perfectly fine.
>
> I am not sure whether this is already supported or planned. But lacked at
> least in Swift 2.1.1.
>
> — Hoon H.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Jacob Bandes-Storch via swift-evolution]

FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
strongSelf = self", and 26 occurrences of "self?." (which should arguably
be changed to the former).

Jacob

On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
wrote:

> +1.
>
> Merely using "self?.something" repeatedly might produce unexpected
> behavior, if self becomes nil between calls. As I mentioned in another
> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>
> In many cases, I use the pattern
>
> somethingAsync { [weak self] in
> guard let strongSelf = self else { return }
>
> // use strongSelf below
> }
>
> But of course, this leads to the unnatural/unwieldy "strongSelf.property"
> all over the place.
>
> I agree with Jordan that "guard let self = self" isn't the most satisfying
> syntax, but it has the advantage of being a *very* minimal grammar/syntax
> change, and its behavior is completely clear as long as the user is already
> familiar with guard.
>
> We should also consider whether "self." is required after "guard let self
> = self". An explicit "guard let self = self" avoids the accidental-capture
> problem, so I think it's reasonable to allow unqualified property access
> for the remainder of the scope.
>
> Jacob
>
> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This has come up before, in a thread called "Proposal: weakStrong self
>> in completion handler closures". I'm still not 100% happy with the
>> syntax, but I like that "guard let" can handle non-Void non-Optional
>> returns well, while 'weakStrong' cannot.
>>
>> Jordan
>>
>>
>> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Currently, weakly captured `self` cannot be bound to `guard let …` with
>> same name, and emits a compiler error.
>>
>> class Foo {
>> func test2(f: ()->()) {
>> // …
>> }
>> func test1() {
>> test2 { [weak self] in
>> guard let self = self else { return } // Error.
>> print(self)
>> }
>> }
>> }
>>
>> Do we have any reason to disallow making `self` back to strong reference?
>> It’d be nice if I can do it. Please consider this case.
>>
>> class Foo {
>> func getValue1() -> Int {
>> return 1234
>> }
>> func test3(value: Int) {
>> print(value)
>> }
>> func test2(f: ()->()) {
>> // …
>> }
>> func test1() {
>> test2 { [weak self] in
>> self?.test3(self?.getValue1()) // Doesn't work because it's not unwrapped.
>>
>> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>>
>> guard self != nil else { return }
>> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>>
>> guard let self1 = self else { return }
>> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
>> new name `self1`.
>>
>> guard let self = self else { return }
>> self.test3(self.getValue1()) // OK.
>>
>> }
>> }
>> }
>>
>> This also can be applied to `if let` or same sort of constructs.
>>
>> Even further, we can consider removing required reference to `self` after
>> `guard let …` if appropriate.
>>
>> guard let self = self else { return }
>> test3(getValue1()) // Referencing to `self` would not be required
>> anymore. Seems arguable.
>>
>> I think this is almost fine because users have to express their intention
>> explicitly with `guard` statement. If someone erases the `guard` later,
>> compiler will require explicit self again, and that will prevent mistakes.
>> But still, I am not sure this removal would be perfectly fine.
>>
>> I am not sure whether this is already supported or planned. But lacked at
>> least in Swift 2.1.1.
>>
>> — Hoon H.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Custom summary for Mirrors?

[Austin Zheng via swift-evolution]

Here are a couple of examples I had in mind.

* Arrays (from test/1_stdlib/Runtime.swift:1348), dumping an array with 5
elements:

BEFORE:
▿ 5 elements
- [0]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacWrite
- [1]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacPaint
- [2]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.FileMaker
▿ [3]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.ClarisWorks
- ClarisWorks: true
   ▿ [4]:
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.HyperCard
- HyperCard: false

AFTER:
▿ [a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacWrite,
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacPaint,
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.FileMaker,
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.ClarisWorks(true),
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.HyperCard(false)]
- [0]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacWrite
- [1]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacPaint
- [2]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.FileMaker
▿ [3]:
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.ClarisWorks(true)
- ClarisWorks: true
▿ [4]:
a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.HyperCard(false)
- HyperCard: false

* Dictionaries (from test/1_stdlib/ReflectionHashing.swift:43):

BEFORE:
▿ 5 key/value pairs
  ▿ [0]: (2 elements)
- .0: Four
- .1: 4
  ▿ [1]: (2 elements)
...

AFTER:
▿ ["Four": 4, "One": 1, "Two": 2, "Five": 5, "Three": 3]
  ▿ [0]: ("Four", 4)
- .0: "Four"
- .1: 4
  ▿ [1]: ("One", 1)
...

* Dumping a CGRect (from test/1_stdlib/Reflection_objc.swift):

BEFORE:
(50.0, 60.0, 100.0, 150.0)

AFTER:
__C.CGRect(origin: __C.CGPoint(x: 50.0, y: 60.0), size: __C.CGSize(width:
100.0, height: 150.0))

Let me know if you'd like more, although most are variants on the above.

Best,
Austin



On Tue, Jan 5, 2016 at 5:37 PM, Dave Abrahams  wrote:

>
> On Jan 5, 2016, at 5:28 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Joe,
>
> I respect the choice of the team to use Custom[Debug]StringConvertible in
> lieu of summary. At the same time, in my opinion the output of dump() has
> become significantly more difficult to read (c.f. unit tests in
> https://github.com/apple/swift/pull/838/files).
>
>
> Specific examples of readability regressions, please?
>
> Would you and the team be open to exploring alternative solutions that
> improve the readability of dump() without increasing API surface area?
>
>
> Sure.
>
> For example, perhaps the reflection machinery itself should have special
> handling for some of the built-in types. If not, I'll consider this
> discussion thread complete.
>
> Thanks,
> Austin
>
>
>
> On Tue, Jan 5, 2016 at 3:22 PM, Jordan Rose  wrote:
>
>> Getting custom summaries for the common CG types certainly seems
>> reasonable. We'd have to get approval from the appropriate teams at Apple,
>> but I can't see any objections.
>>
>> Jordan
>>
>>
>> On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I believe 'summary' is obsolete, and you're supposed to use
>> Custom[Debug]StringConvertible to customize your type's reporting now.
>>
>> -Joe
>>
>> On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi all,
>>
>> I'd like to gauge reaction for a proposal I was considering: adding to
>> the standard library's Mirror type a 'summary' property, and the option to
>> initialize a Mirror with a custom summary. If no custom summary is
>> provided, the summary would default to the string produced by calling
>> String(reflecting: subject) on the subject at the time of mirror creation.
>>
>> Some context: right now, there are two APIs for mirrors in the standard
>> library: CustomReflectable, which is publicly exposed and relies on the
>> conforming type creating a Mirror object, and _Reflectable, which relies on
>> the conforming type having a companion type conforming to _MirrorType. A
>> short-term goal is to migrate the standard library's types off the
>> _Reflectable API and have them use the CustomReflectable API, and changing
>> dump() accordingly.
>>
>> The extant implementation of dump() uses a property on _MirrorType called
>> "summary". (This is where e.g. "4 elements" comes from when you dump() an
>> array.) "summary" is absent from Mirror or any types related to
>> CustomReflectable. I asked Joe Groff about this and the rationale was that
>> it was deemed too similar to debugDescription (or String(reflecting: foo))
>> to be worth carrying over.
>>
>> I would like to suggest that there might be a purpose for "summary":
>>
>> - Types with children, especially container types like arrays, often
>> print out a description of their children as 

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Chris Lattner via swift-evolution]

> On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution 
>  wrote:
> 
> I also think that Float and Double are not ideal type names but I also agree 
> with many of the concerns that have been raised.
> 
> 
> Why not simply use (the existing) Float32 and Float64 while keeping 
> everything else equal?

What perceived problem are you solving?

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Greg Parker via swift-evolution]

> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor > > wrote:
>> 
>> There are better mechanisms for this than +load. But one would have to deal 
>> with the dylib loading issue and the need to enumerate root classes to get 
>> to a complete implementation. Frankly, I don’t think this level of 
>> Objective-C runtime hackery is worth the effort, hence my suggestion to make 
>> the existing behavior explicit.
> 
> Yeah, +load was just to throw together a quick-and-dirty demonstration, and 
> not what you’d actually use. You have a point about libraries and bundles; 
> you’d have to hook into that and rescan each time new code was dynamically 
> loaded. However, the enumeration of classes only seems to take around 0.001 
> seconds, so I don’t think it’s terrible.

Enumeration of classes is terrible: it forces the runtime to perform lots of 
work that it tries very hard to perform lazily otherwise. I would expect your 
measured cost to be much higher if you had linked to more high-level libraries 
(UIKit, MapKit, etc).


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution