date:20160622


> On Jun 22, 2016, at 10:14 PM, Alsey Miller via swift-evolution 
>  wrote:
> 
> Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null 
> is more performant (no ARC or memory allocation) than NSNull, and will be 
> needed for Swift JSON decoders and libraries that want to use struct value 
> types, and be free from classes for their model layer.
> 
I assume you are thinking of [String:SomeRootJSONProtocol] as the Object type? 
However, once you reference the data as a protocol however, it will be promoted 
and stored as a reference type.

I’ve preferred a similar approach to the following for JSON (although this 
isn’t my code): 
https://gist.github.com/dorentus/1e2132edfb174028bf11#file-json-swift-L30-L38

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

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread Jose Cheyo Jimenez via swift-evolution

In addition to the technical review, I would like to point out that the 
definition of Arithmetic appears to be missing some underscores in 
add/adding/subtract/subtracting
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
> 
>   * What is your evaluation of the proposal?

I’m so glad this work is being done!

For Integer, does the presence of signBit indicate an expectation that signed 
Integers will have a two's complement representation?

For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what 
situations would you have an overflow? I could only come up with something like 
Int.min.dividedWithOverflow(-1).

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

Yes, oh yes.

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

It looks like a significant improvement. 

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

I combed the proposal for questions, although most were answered by the time I 
hit the end.

-DW

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

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

>   * What is your evaluation of the proposal?
-1. It removes a feature that I love about Swift.
When `for;;;` was removed, I thought to my self , we have `where` to help on 
tricky situations. 
Removing `where` would make working with for loops more terse. 
I do not like using guards in my for loops; I would rather use the old for;; 
than to use guards.
Guards are just not the way I think about loops in general. (Plus I think they 
are ugly)

It makes sense why SE-0099 removed `where`. We got a whole lot more 
functionality by giving up `where`. 
This proposal SE-0105 is taking away functionality by forcing guards continues 
and breaks. 
There is not additional functionality being suggested other than forcing one 
way of doing things. 

I don’t think renaming where to `if` helps any. I don’t like the idea even 
though I love the way python uses it. 
Using `if` instead of `where` will overload yet another pattern on top of `if`. 
(if case, if let, if var, if if if)

I want more features to be added to 'for in whee’ loops, not them being taken 
way. 

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
nope. 
>   * Does this proposal fit well with the feel and direction of Swift?
don’t think so. 
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
python. 

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
I followed the proposal and discussions. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Patrick Smith via swift-evolution

There’s a great discussion going on here, and I don’t mean to distract. But I 
want to ask: to get an infinite sequence using the Swift standard library, 
you’re going to have to create one yourself, say using the new `sequence()` 
functions? There’s nothing built in that is already infinite, so people will 
know what they are creating, that’s the explicit step, and there’s no need to 
have safety to infinitely loop over something. And if someone accidentally 
creates an unwanted infinite loop, that’s a fix in the creation of the 
sequence, not in its looping.

Patrick

> On 23 Jun 2016, at 11:12 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Sure, it’s not wrong in the sense that sometimes an infinite loop is valid.  
> But I think it would almost always be wrong (an accident) in practice.  If 
> you really want to loop over an infinite sequence maybe it’s a good thing to 
> require you to do that explicitly.

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence


> On Jun 22, 2016, at 7:12 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 22, 2016, at 6:41 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Wed Jun 22 2016, Matthew Johnson > > wrote:
>> 
 On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution 
 > wrote:
>>> 
>>> I believe this is a problem that should be solved.  
>>> 
>>> I also believe distinguishing between finite and infinite sequences is
>>> a good idea (along with preventing for..in from being used with an
>>> infinite sequence)
>> 
>> for..in over an infinite sequence is not necessarily wrong.  I'm not
>> confident it should be prevented.  It's certainly less dangerous than
>> using `forEach`, from which there is no possibility of escape.
> 
> Sure, it’s not wrong in the sense that sometimes an infinite loop is valid.  
> But I think it would almost always be wrong (an accident) in practice.  If 
> you really want to loop over an infinite sequence maybe it’s a good thing to 
> require you to do that explicitly.
The problem is that the only way to know a loop is infinite reliably is to have 
the developer opt-in. 

Also, operations on said infinite sequence might or might not be infinite - a 
Fibonacci sequence.first { $0 == 0 } would go forever since the sequence starts 
with 1 and never decreases.

Then we have the issue that we have finite sequences which will still take 
longer than the typical hardware lifetime.

let x = 0..> That's not an over-constraint.  Multi-pass-ness *is* the fundamental
>> distinction between Sequence and Collection.  AFAIK there's no multipass
>> sequence that cannot support indices.

That indices are expected to be O(1) in Collection (under penalty of 
documentation and/or surprise) means that there is an impact above just 
implementing an Iterator for implementing a Collection, is there not?
> 
>> 
>> FWIW, I'm also not entirely confident that single-pass things should be
>> part of *this* picture at all.  It might be that single-pass things
>> should be entirely separate and forced to be reference types where
>> traversal mutates the instance.  
> 
> This seems like a reasonable direction.
> 
>> E.g., the current Iterator could gain a
>> class constraint and become the only representation of single-pass
>> sequences.
> 
> Hmm.  I would have to give this more thought.  Do we really want to require 
> all conformances of `Iterator` to be reference types?  What would be the 
> performance impact of that?

I am also unclear here - are you talking of moving the current functionality 
used for Iterator someplace else, or creating a new SinglePassIteratorProtocol? 
 

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

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 7:42 PM, Matthew Johnson  wrote:
>
> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko  wrote:
>
> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>  wrote:
>
> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> Rejection: "The feedback on the proposal was generally positive about the
> idea of renaming these protocols, but the specific names in the proposal are
> not well received, and there is no apparent confluence in the community on
> better names.  The core team prefers discussion to continue -- if/when there
> is a strong proposal for a better naming approach, we can reconsider
> renaming these."
>
> John McCall: "To be clear, I don't care about the name.  If you want to
> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
> the conversation into the muck again. :)  It's the design of the
> requirements that I'm pretty opposed to revisiting."
>
> The Problem: This is really the last chance to rationalize this across the
> language and to evaluate whether other protocol groups should have a core
> scheme for naming.
>
>
> Hi Erica,
>
> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
> and me from the last time this was discussed.  Unfortunately I can't
> find the exact email, so I can't provide a link.
>
> - The "literal" protocols are not about conversion, they are about
> adopting a certain syntax provided by the language.  "Convertible" in
> the name is a red herring: a type can't be convertible from an integer
> literal because there is no "IntegerLiteral" entity in the type
> system.  The literal *becomes* typed as the corresponding literal type
> (e.g., Int or String), and as far as the user at the call site is
> concerned, there is no visible conversion (even if one is happening
> behind the scenes).
>
> Our suggestion was to focus on the "adopting the syntax" part.  We
> suggested moving the "literal convertible" protocols into a
> pseudo-namespace "Syntax".  It could be implemented like this:
>
> protocol _IntegerLiteralSyntax {}
> enum Syntax {
>  typealias IntegerLiteral = _IntegerLiteralSyntax
> }
>
> And used like this:
>
> struct Int : Syntax.IntegerLiteral {}
>
>
> I’m working on a draft of this proposal right now.  I have a couple
> questions.
>
> First, I’d like to list the standard library team as co-authors if you
> desire because this is really your idea.  Let me know what you would prefer.

Thank you.  I don't mind either way.

> Second, I wonder if it might make more sense to name the protocols
> `Syntax.IntegerLiteralInitializable`.  Dave has opposed `Initializable` as a
> general convention because it implies pure syntax and doesn’t carry any
> semantics.  But in this case the semantics *are* essentially the syntax.
> Erica pointed out to me off list that at the usage site the
> `Syntax.IntegerLiteral` names could confuse somebody into thinking in terms
> of *isa* rather than *can do* (i.e. Int is an IntegerLiteral rather than Int
> can be *initialized* with an IntegerLiteral).
>
> Please let me know if this name change would be acceptable to the standard
> library team or may be met with resistance.  I want this proposal to be
> acceptable to the team from the start.

IIRC the consensus that Dave, Max and I reached was
`Syntax.IntegerLiteral`, but this does not represent the opinion of
the core team.  (We did not talk to the whole team, just the three of
us.)

I think the possibility of confusion is very small because users will
not refer to the protocol as 'IntegerLiteral', it will be qualified as
'Syntax.IntegerLiteral'.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-22 Thread Patrick Smith via swift-evolution

Yes, I’m all for removing this syntax which seems to confuse people with what 
it actually does. Having to write more explicit code with a `guard` or 
`.filter` is better than people unexpectedly creating bugs.

I’d say remove it for Swift 3, allowing a potential replacement for this 
functionality to be an addition and not a breaking change. It’s kind of like 
pruning a tree back to prepare it for new growth.

(I like Xiaodi’s suggestion of replacing `where` with `if`, but I imagine that 
would be a separate proposal, but interested in hear other’s thoughts on it, 
although I’ve probably missed some in the discussion.)

Patrick

> On 23 Jun 2016, at 2:12 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now 
> and runs through June 29. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
> 
> 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 contribute to 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 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,
> 
> -Chris Lattner
> 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] [swift-evolution-announce] [Returned for revision] SE-0077: Improved operator declarations

2016-06-22 Thread Chris Lattner via swift-evolution


> On Jun 22, 2016, at 8:24 PM, Joe Groff  wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>  
> 
> 
> Hello Swift Community,
> 
> The review of SE-0077: "Improved operator declarations" ran from May 17...23. 
> On June 22, 2016, the core team decided to return the first version of this 
> proposal for revision. The core design proposed is a clear win over the Swift 
> 2 design, but the core team feels that revisions are necessary for usability 
> and consistency with the rest of the language:

One clarification: we still consider this to be in scope for Swift 3.  Anton, 
we would appreciate it if you could revise the proposal, but if not, let us 
know.

Thanks!

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 2:57 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>  “Iterators,” please.

That makes me happy - for some reason I thought it was still GeneratorProtocol

>> destructively, but such Generators would not conform to the needs of
>> Sequence. As such, the most significant impact would be the inability
>> to use such Generators in a for..in loop, 
> 
> Trying to evaluate this statement, it's clear we're missing lots of
> detail here:
> 
> * Would you remove Sequence?
> * If so, what Protocol would embody “for...in-able?”
No, I would just remove the allowance in the documentation and API design for a 
destructive/consuming iteration. Sequence would be the interface to getting 
access to repeatable iteration, without the need for meeting the other 
requirements for Collection.

Sequence would be what java would refer to as Iterable, C# refers to as 
IEnumerable<>, but perhaps it is closest to the Enumerable mixin module in Ruby 
in terms of default utility methods supplied based on an implementation of 
‘each’ (forEach() in Swift). Sequence is for…in-able because Sequence defined 
makeIterator(). The only difference is that subsequent calls to makeIterator() 
are expected to return conceptually equivalent elements in the same order.

> * If not, would you remove Collection?

I see value in the other differentiating factors between Collection (not 
needing to be indexable, not needing to return a definitive count, and possibly 
not needing to be finite - although it sounds like collections may be 
effectively infinite to the extent that the integer type returned from count 
allows.

A Fibonacci-providing sequence can be written as a rather small closure, while 
my understanding of Collection would require either more code (that I likely 
don’t need), rather funky indexes that preserve state internally, and/or a 
switch to a non-iterative algorithm.

> * What role would Iterator play?

So far I haven’t considered whether IteratorProtocol would be destructive, 
since my motivation was primarily around consistent Sequence behavior. By that 
light, an Iterator returned by a method other than Sequence.makeIterator() 
could still consume data. However, I wonder if supporting such Iterators 
provides enough value to be worthwhile - there aren’t that many methods that 
consume an IteratorProtocol (the AnyIterator<> initializer is the only one I 
know of) and without applicability to a Sequence such an iterator has less 
value.

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

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

2016-06-22 Thread Charlie Monroe via swift-evolution

This kind of sounds like the proposal to have implicit return in guard 
statements.

I agree with John that this kind of feels incosistent and obscure.

An alternative that could be used everywhere though may look like this:

func myFunc() -> String {
autoreturn {
return "Hello"
}

if Date.today.isSunday {
return "Sunday"
}
}

The `autoreturn` would act as `defer` on paths that do not have a return 
statement, would be applicable in any function (i.e. any return type allowed).

I can see this being useful if you need to return default value that needs to 
have some further initialization and the method is quite long.

> On Jun 22, 2016, at 10:55 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 22, 2016, at 1:36 PM, James Froggatt via swift-evolution 
>> > wrote:
>> Welcome, Logan.
>> 
>> Functions currently return the empty tuple, ‘()’, by default. Void is a 
>> typealias to the empty tuple type. It is also possible to write ‘return ()’ 
>> explicitly, rather than just ‘return’. (This is generally a detail of the 
>> language, so may be unfamiliar)
> 
> It is more correct to say that it is illegal to reach the end of a function 
> whose return type is not ().  Falling off the end of a function that returns 
> ()? will not implicitly return Optional.Some(()); it will produce an error:
> 
> (swift) func foo() -> ()? {}
> :1:20: error: missing return in a function expected to return 
> '()?'
> func foo() -> ()? {}
>^
> 
> We could amend this rule to permit reaching the end of an optional-returning 
> function, with the semantics of returning nil.  I do not, however, think that 
> would be a good idea; it turns simple mistakes into bugs, feels inconsistent 
> in the language, and is unnecessarily obscure for readers.
> 
> John.
> 
>> 
>> It is unclear in your proposal as it stands which (if any) a function 
>> returning ‘()?’ would use as its default: (), or nil?
>> Would the ‘nil’ keyword still be required when writing return explicitly?
>> 
>> While this does match behaviour present in other parts of the language, and 
>> I see the benefit of having implicit returns in this otherwise 
>> straightforward case, I'm struggling to decide as to whether this is worth 
>> the extra complexity of having two orthogonal implicit return mechanisms.
>> 
>>  Begin Message  
>> Group: gmane.comp.lang.swift.evolution 
>> MsgID: <4ac6f31e-9e46-47b3-8cae-b5edd0404...@gmail.com 
>> > 
>> 
>> I believe Swift should no longer require an explicit return on all functions 
>> and instead do an implicit nil return if the function reaches the end of its 
>> control flow and has an optional return type.
>> 
>> This could be useful to keep code clean and compact, by only having to write 
>> code for cases that our function handles and just returning nil otherwise 
>> automatically.
>> 
>> 
>> Consider:
>> 
>> func toInt(string : String?) -> Int?
>> {
>> if let s = string
>> {
>> return s.intValue
>> }
>> 
>> //Make this return implicitly happen instead of requiring it.
>> //return nil 
>> }
>> 
>> 
>> 
>> This also very much goes along with the implicit return within a guard 
>> statement that I have seen proposed. Here:
>> 
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string else {
>> //this could be implicitly returned using the same logic, since the guard 
>> means we have reached the end of our code path without returning
>> //return nil 
>> }
>> return s.toInt()
>> }
>> 
>> 
>> These methods could be re-written as so:
>> 
>> This could allow us to write the examples below much cleaner
>> func toInt(string : String?) -> Int?
>> {
>> if let s = string
>> {
>> return s.toInt()
>> }
>> }
>> 
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string else {} 
>> return s.toInt()
>> }
>> 
>> // it would be even cooler if we could omit the else {} and make them not it 
>> return by default. But that’s another thing all together
>> func toInt(string: String?) -> Int?
>> {
>> guard let s = string
>> return s.toInt()
>> }
>> 
>> 
>> Thanks for reading my first post to the Swift open source discussion board!
>> -Logan
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> - End Message - 
>> 
>> 
>> 
>> From James F
>> ___
>> 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] [Review] SE-0105: Removing Where Clauses from For-In Loops

2016-06-22 Thread Charlie Monroe via swift-evolution

>   * What is your evaluation of the proposal?

-1. As I was all along during the discussion here, I find the ability to 
automatically filter the sequence using where as useful and a nice language 
feature. I do not find the syntax confusing, on the other hand the 
alternatively suggested replacement with "if" is confusing to me.

IMHO the frequency of use is not a very good point since as I've mentioned 
during the discussion, the fact that it's not very used in popular Swift 
repositories may be partially given that this feature isn't documented well - 
the Swift Programming Language book on Swift.org doesn't mention this and 
neither does any material on developer.apple.com.

It was pointed out that neither does the stdlib use it frequently, but that's 
quite a specific piece of work, not reflecting the common use cases.

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

No.

>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have 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?

Read + discussion.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> 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

[swift-evolution] [Pitch] Add Null struct to Foundation

2016-06-22 Thread Alsey Miller via swift-evolution

Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null is 
more performant (no ARC or memory allocation) than NSNull, and will be needed 
for Swift JSON decoders and libraries that want to use struct value types, and 
be free from classes for their model layer.


Coleman,





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

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

2016-06-22 Thread Chris Lattner via swift-evolution

Hello Swift community,

The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now 
and runs through June 29. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md

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 contribute to 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 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,

-Chris Lattner
Review Manager


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

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

2016-06-22 Thread L. Mihalkovic via swift-evolution


> On Jun 22, 2016, at 7:59 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>>> 
>>> I would really like to see submodules, but I think there would still be 
>>> valid uses for `fileprivate` even with them.  But of course we would need 
>>> to know the details of submodules to have a good discussion about that so 
>>> it’s a topic for the future. :)
>> 
>> I wonder what became of this: 
>> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18
> 
> As the author of that document, it became clear (or maybe “it became murky”) 
> that everyone wants different things from submodules, both for compiling 
> their own targets and for importing other people’s targets.

Surveying the larger github swift projects it is clear that people currently 
struggle to structure code when compared with c++, java, c# or even scala. It 
may just be that many come directly from objc. It is particularly visible on 
the server side libs out there where a module sometimes mean a class and a 
protocol... Without getting sidetracked too much it should be possible to 
devise a limited improvement on the current situation, maybe even outside of 
this community to avoid some of the endless meandering i have seen on 'hot' 
topics.


> I’d almost suggest avoiding the word if you want to propose any of myriad 
> features related to them:
> 
> - importing a subset of APIs
> - having APIs not imported by default with the top-level module
> - C++ namespacing within a module
> - C++ namespacing within another module
> - breaking up compilation units (i.e. not compiling the entire module as one 
> unit)
> - adding another access level between internal and fileprivate.
> - adding another access level between fileprivate and private.
> - something else?
> 
> (still catching up on the main thread, but I think Robert and Matthew are 
> both right: we need to explicitly amend the proposal, and the behavior we 
> want is fairly obvious)
> 
> Jordan
> ___
> 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] [Returned for revision] SE-0077: Improved operator declarations

2016-06-22 Thread Joe Groff via swift-evolution

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May 17...23. 
On June 22, 2016, the core team decided to return the first version of this 
proposal for revision. The core design proposed is a clear win over the Swift 2 
design, but the core team feels that revisions are necessary for usability and 
consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for precedence 
group attributes doesn’t have a precedent elsewhere in Swift. Furthermore, it 
isn’t clear which relationship < and > correspond to in the precedence syntax. 
The core team feels that it’s more in the character of Swift to use 
colon-separated “key-value” syntax, with associativity, strongerThan, and 
weakerThan keyword labels:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

-If “stronger” and “weaker” relationships are both allowed, that would enable 
different code to express precedence relationships in different, potentially 
confusing ways. To promote consistency and clarity, the core team recommends 
the following restriction: Relationships between precedence groups defined 
within the same module must be expressed exclusively in terms of strongerThan. 
weakerThan can only be used to extend the precedence graph relative to another 
module’s groups, subject to the transitivity constraints already described in 
the proposal. This enforces a consistent style internally within modules 
defining operators.

- The proposal states that precedence groups live in a separate namespace from 
other declarations; however, this is unprecedented in Swift, and leads to 
significant implementation challenges. The core team recommends that precedence 
groups exist in the same namespace as all Swift declarations. It would be an 
error to reference a precedence group in value contexts.

- Placing precedence groups in the standard namespace makes the question of 
naming conventions for precedencegroup declarations important. The core team 
feels that this is an important issue for the proposal to address. As a 
starting point, we recommend CamelCase with a -Precedence suffix, e.g. 
AdditivePrecedence. This is unfortunately redundant in the context of a 
precedencegroup declaration; however, precedencegroups should be rare in 
practice, and it adds clarity at the point of use in operator declarations in 
addition to avoiding naming collisions. The standard library team also requests 
time to review the proposed names of the standard precedence groups

- This proposal quietly drops the assignment modifier that exists on operators 
today. This modifier had one important function–an operator marked assignment 
gets folded into an optional chain, allowing foo?.bar += 2 to work as foo?(.bar 
+= 2) instead of failing to type-check as (foo?.bar) += 2. In practice, all 
Swift operators currently marked assignment are at the equivalent of the 
Assignment precedence level, so the core team recommends making this optional 
chaining interaction a special feature of the Assignment precedence group.

- This proposal also accidentally includes declarations of &&= and ||= 
operators, which do not exist in Swift today and should not be added as part of 
this proposal.

Thanks Anton Zhilin for the proposal, and thanks to everyone who participated 
in the review! I will be taking over from Chris as review manager for the next 
round of revision.

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

[swift-evolution] [Accepted] SE-0089: Renaming String.init(_: T)

2016-06-22 Thread Chris Lattner via swift-evolution

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Hello Swift Community,

The second review of SE-0089: "Renaming String.init(_: T)" ran from June 
4...7. The proposal is *accepted* for Swift 3.  

The feedback from the community on this second round was light, which indicates 
that the extensive iteration on earlier rounds brought this to a good place.  
The core team discussed other possibilities for the parameter label (e.g. from: 
instead of describing:) but ended up agreeing that a more explicit 
“describing:” label is the best fit for this API.

Many thanks to Austin Zheng and Brent Royal-Gordon for driving this discussion, 
iterating on the design, and writing a great proposal!  I filed SR-1881 to 
track implementation of this work.  This would be a great project for someone 
who wants to work on the standard library.

-Chris Lattner
Review Manager


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

Re: [swift-evolution] Partial list of open Swift 3 design topics

2016-06-22 Thread Karl via swift-evolution

> - Bool is a simple enough concept to not need a family of protocols.

Literally, the most fundamental concept.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Partial list of open Swift 3 design topics

2016-06-22 Thread Chris Lattner via swift-evolution

On Jun 22, 2016, at 6:16 PM, Xiaodi Wu  wrote:
>  - Remove Boolean protocol.
> ^^^
> What's the thinking behind this particular item?
>  

“Boolean” isn’t pulling its weight:
- It only abstracts over Bool and ObjCBool.
- It only enables a few operations on ObjCBool, which are not very important.
- ObjCBool is a bridging problem, and we don’t handle bridging by introducing 
common protocols (e.g. in the case of String vs NSString, we don’t introduce a 
common “Stringable” protocol.

Further, it complicates the model:
 - People are confused by it and the similar but very different Bool type.
 - Bool is a simple enough concept to not need a family of protocols.

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

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Matthew Johnson via swift-evolution


> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko  wrote:
> 
> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
> > wrote:
>> Proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>> 
>> Rejection: "The feedback on the proposal was generally positive about the
>> idea of renaming these protocols, but the specific names in the proposal are
>> not well received, and there is no apparent confluence in the community on
>> better names.  The core team prefers discussion to continue -- if/when there
>> is a strong proposal for a better naming approach, we can reconsider
>> renaming these."
>> 
>> John McCall: "To be clear, I don't care about the name.  If you want to
>> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
>> the conversation into the muck again. :)  It's the design of the
>> requirements that I'm pretty opposed to revisiting."
>> 
>> The Problem: This is really the last chance to rationalize this across the
>> language and to evaluate whether other protocol groups should have a core
>> scheme for naming.
> 
> Hi Erica,
> 
> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
> and me from the last time this was discussed.  Unfortunately I can't
> find the exact email, so I can't provide a link.
> 
> - The "literal" protocols are not about conversion, they are about
> adopting a certain syntax provided by the language.  "Convertible" in
> the name is a red herring: a type can't be convertible from an integer
> literal because there is no "IntegerLiteral" entity in the type
> system.  The literal *becomes* typed as the corresponding literal type
> (e.g., Int or String), and as far as the user at the call site is
> concerned, there is no visible conversion (even if one is happening
> behind the scenes).
> 
> Our suggestion was to focus on the "adopting the syntax" part.  We
> suggested moving the "literal convertible" protocols into a
> pseudo-namespace "Syntax".  It could be implemented like this:
> 
> protocol _IntegerLiteralSyntax {}
> enum Syntax {
>  typealias IntegerLiteral = _IntegerLiteralSyntax
> }
> 
> And used like this:
> 
> struct Int : Syntax.IntegerLiteral {}

I’m working on a draft of this proposal right now.  I have a couple questions.  

First, I’d like to list the standard library team as co-authors if you desire 
because this is really your idea.  Let me know what you would prefer.

Second, I wonder if it might make more sense to name the protocols 
`Syntax.IntegerLiteralInitializable`.  Dave has opposed `Initializable` as a 
general convention because it implies pure syntax and doesn’t carry any 
semantics.  But in this case the semantics *are* essentially the syntax.  Erica 
pointed out to me off list that at the usage site the  `Syntax.IntegerLiteral` 
names could confuse somebody into thinking in terms of *isa* rather than *can 
do* (i.e. Int is an IntegerLiteral rather than Int can be *initialized* with an 
IntegerLiteral).  

Please let me know if this name change would be acceptable to the standard 
library team or may be met with resistance.  I want this proposal to be 
acceptable to the team from the start.

Matthew

> 
> - For protocols that are representing conversions between types that
> actually exist in the library, there is not enough precedent yet to
> make a general conclusion and standardize a pattern.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/

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

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

2016-06-22 Thread plx via swift-evolution

You’re right on the specifics, of course.

To be clear I am more concerned about accidental shadowing with such 
subscripts; picture starting initial development with only the generic 
subscript from the proposal, writing some code that uses it…and then at some 
later point in time importing a module that defines the `RawRepresentable` 
variant, which would subtly shift how your code got interpreted.

This isn’t anything that couldn’t happen today with plain-old functions, of 
course — and it can be worked around in various ways, if you know it happens — 
but given the IMHO much higher likelihood of "name collisions” (you’re correct 
you can label the subscript arguments, but I doubt most subscripts will opt to 
do so)…it seems far likelier we’ll see resolution-modifying collisions under a 
proposal like this, should it be introduced.

But I could be very wrong, and in any case this proposal should probably wait 
until at least August, as per suggestion.

> On Jun 22, 2016, at 9:29 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jun 22, 2016, at 9:11 AM, plx via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jun 22, 2016, at 8:28 AM, T.J. Usiyan >> > wrote:
>>> 
>>> plx: wouldn't the same overload resolution strategy be appropriate here? 
>>> "most specific choice, otherwise diagnostic”
>> 
>> I’d assume it’d be good enough for most cases, certainly; I’d love to turn 
>> out to be needlessly scaremongering here, too.
>> 
>> But (hopefully unintentionally!) it seems like you could easily wind up with 
>> scenarios like this:
>> 
>>   // from proposal:
>>   public subscript(key: Key) throws -> T {
>> guard let value = self[key] else { throw ... }
>> guard let ofType = value as? T else { throw ... }
>> return ofType
>>   }
>> 
>>   // an annoying addition:
>>   public subscript(key: Key) throws -> T {
>> guard let v = self[key] else { throw ... }
>> guard let rawValue = v as? T.RawValue else { throw ... }
>> guard let converted = T(rawValue: rawValue) else { throw ... }
>> return converted
>>   }
>> 
>>   // assume `Foo:RawRepresentable`:
>>   let foo: Foo = json["foo"]
>> 
>> …and similar, where I’d assume the `T:RawRepresentable` would “win”, but I’m 
>> not sure *how* you could force use of the *other* subscript in the above.
>> 
>> This isn’t really a new problem, but it seems likelier to be encountered if 
>> generic subscripts become allowed, due to all subscripts having the same 
>> “name”.
> 
> This isn’t exactly true.  External argument labels are considered part of the 
> “name” in Swift.  Subscripts parameters don’t get external labels 
> automatically like other functions / methods do, but you can still add one if 
> you *want* the ability to disambiguate.  
> 
> Of course this won’t help if you require the ability to use both subscripts 
> without a label but is worth noting.  It is also worth noting that this 
> behavior is no different from that of any other function or method - if the 
> name (including external argument labels) matches the most specific overload 
> will always be selected.
> 
> One way to make your example work properly when `T` is `RawRepresentable` and 
> the dictionary actually contains an instance of `T` is to add an extra check 
> for that case:
> 
>   public subscript(key: Key) throws -> T {
> guard let v = self[key] else { throw … }
> 
> // extra check here in case the value is *already* T and therefore does 
> not require conversion.
> if let value = v as? T { return value }
> 
> guard let rawValue = v as? T.RawValue else { throw ... }
> guard let converted = T(rawValue: rawValue) else { throw ... }
> return converted
>   }
> 
>> 
>> But again I’d like to be wrong about the issue (or at least the severity).
>> 
>>> 
>>> separately:
>>> Are there any subscripts in the standard library that would be 
>>> throwing/generic but can't be?
>>> 
>>> 
>>> On Wed, Jun 22, 2016 at 9:13 AM, plx via swift-evolution 
>>> > wrote:
>>> Prefacing the below with a “I am well-aware this proposal likely won’t make 
>>> it into Swift 3”:
>>> 
>>> A feature like this would be nice to use, but before I could get behind any 
>>> proposal along these lines it I’d want to see it include an explicit 
>>> strategy for disambiguation.
>>> 
>>> EG: in your example, your generic subscript uses `self[key]`, and 
>>> presumably expects that to use the “original” subscript…and not the generic 
>>> subscript being defined.
>>> 
>>> I think that’s reasonable in that specific case, but it doesn’t seem 
>>> unreasonable to anticipate this proposal introducing ambiguities that would 
>>> need explicit disambiguation…and for which explicit type annotation may not 
>>> always be adequate to resolve (I could be wrong here, though). 
>>> 
>>> This would need addressing

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

2016-06-22 Thread Trent Nadeau via swift-evolution

On Wed, Jun 22, 2016 at 2:04 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0095: Replace `protocol` syntax with
> `Any`" begins now and runs through June 27. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>
> 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 contribute to 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?
>
+1. I think this syntax shorter and easier to read.

> * 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?
>
Yes. It improves the use of protocols in generics and existentials.

> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
Rust uses `+` with its traits, with basically the same meaning.

> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
Read the proposal and followed the email threads.

>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



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

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

Let's not go through more churn with `pointee`. It's already just been
changed from `memory`.
On Wed, Jun 22, 2016 at 21:02 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Hi All,
>
> A couple of weeks ago we started to notice that we had some poorly-named
> closure parameters and argument labels in the standard library, so we
> did a complete audit of the standard library's APIs and came up with a
> preliminary proposal for changes, which we applied in a branch and you
> can review in https://github.com/apple/swift/pull/2981.  Let's please
> carry on further discussion here rather than in the pull request, though.
>
>
> *-  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)*
> * -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)*
> * -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both
> `true`, then*
> * -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)*
> * +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)*
> * +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)*
> * +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both
> `true`, then*
> * +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)*
>
> I like this change!
>
> *-func forEach(_ body: (S.Iterator.Element) -> ())*
> *+func forEach(invoke body: (S.Iterator.Element) ->
> ())*
>
> Adding an external label makes sense here. This is a procedural call and
> using it within the parens should have a "code ripple".
>
> That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
> `runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. This also
> applies
> where there's a `body` label instead of an empty external label.
>
> *-public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {*
> *+public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) ->
> Void) {*
>
> For any with/external label pair, I'd prefer `with-do` or `with-perform`
> over `with-invoke`.
>
> *-  return IteratorSequence(it).reduce(initial, combine: f)*
> *+  return IteratorSequence(it).reduce(initial, accumulatingBy: f)*
>
> For `reduce`, I'd prefer `applying:` or `byApplying:`
>
> Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,
> min/max, byOrdering
>
> *-  ).encode(encoding, output: output)*
> *+  ).encode(encoding, sendingOutputTo: processCodeUnit)*
>
> How about `exportingTo`?
>
>
> *-  tempwords.sort(isOrderedBefore: <)*
> *+  tempwords.sort(orderingBy: <)*
>
> With `sort` and `sorted`, I'd prefer `by:`
>
> *-  if !expected.elementsEqual(actual, isEquivalent: sameValue) {*
> *+  if !expected.elementsEqual(actual, comparingBy: sameValue) {*
>
> I'm torn on this one. I don't like but I don't have a good solution.
>
> *-  /// for which `predicate(x) == true`.*
> *+  /// for which `isIncluded(x) == true`.*
> *-  _base: base.makeIterator(), whereElementsSatisfy: _include)*
> *+  _base: base.makeIterator(), suchThat: _include)*
>
> How about simply `include` for both? I get the `is` desire but it's being
> tossed away
> in a lot of other places in this diff. and `suchThat` feels out of place.
>
> *-  || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {*
> *+|| u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) })
> {*
>
> I assume the challenge here is differentiating contains(element) from
> contains(closure).
> This feels predicate-y, which is why I put it near the predicates. But I
> think something
> like `containsElement(where:)` works better.
>
> * -let result = try
> base._withUnsafeMutableBufferPointerIfSupported(body)*
> *+let result = try
> base._withUnsafeMutableBufferPointerIfSupported(invoke: body)*
>
> I hate "ifSupported" but that's another discussion
> (withSupportedUnsafeMutableBufferPointer,
> withAvailableUnsafeMutableBufferPointer, it's all lipstick)
>
> This is procedural, so `do` or `perform` rather than `invoke`
>
> *-  for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {*
> *+  for test in removeFirstTests.filter(*
> *+suchThat: { $0.numberToRemove == 1 }*
>
> The difference between `filter` and `forEach` is that `forEach` is
> explicitly
> procedural while `filter` is functional.  I do not like functional
> chainable
> calls being modified to use explicit external labels in this way.
>
> I'd prefer no label here.
>
> *public func split(*
> *  maxSplits: Int = Int.max,*
> *  omittingEmptySubsequences: Bool = true,*
> *-isSeparator: @noescape (Base.Iterator.Element) throws -> Bool*
> *+separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws
> -> Bool*
>
> I'm torn on this one. It's not the worst ever but something more like
> where/at/when
> makes more sense to me than "separatedWhere/separatedAt/separatedWhen".
>
> *+  count:

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread Steve Canon via swift-evolution

Sent from my iPhone

> On Jun 22, 2016, at 9:32 PM, Karl via swift-evolution 
>  wrote:
> 
> I would like ‘floor’ and ‘ceil’ to be part of the standard library (or some 
> equivalent). It annoys me that I have to import Darwin/Glibc to properly 
> convert between standard library types. Would this go with the initialisers 
> from FloatingPoint on Integer, or somewhere on FloatingPoint?

These should simply be added to FloatingPoint.  I'll write a tiny proposal for 
that.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution 
 wrote:
> 
> 
> Hi All,
> 
> A couple of weeks ago we started to notice that we had some poorly-named
> closure parameters and argument labels in the standard library, so we
> did a complete audit of the standard library's APIs and came up with a
> preliminary proposal for changes, which we applied in a branch and you
> can review in https://github.com/apple/swift/pull/2981.  Let's please
> carry on further discussion here rather than in the pull request, though.

-  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)
 -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)
 -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both `true`, then
 -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)
 +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)
 +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)
 +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both `true`, 
then
 +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)

I like this change!

-func forEach(_ body: (S.Iterator.Element) -> ())
+func forEach(invoke body: (S.Iterator.Element) -> ())

Adding an external label makes sense here. This is a procedural call and
using it within the parens should have a "code ripple".

That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
`runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. This also 
applies
where there's a `body` label instead of an empty external label.

-public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {
+public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> Void) {

For any with/external label pair, I'd prefer `with-do` or `with-perform` 
over `with-invoke`.

-  return IteratorSequence(it).reduce(initial, combine: f)
+  return IteratorSequence(it).reduce(initial, accumulatingBy: f)

For `reduce`, I'd prefer `applying:` or `byApplying:`

Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,
min/max, byOrdering

-  ).encode(encoding, output: output)
+  ).encode(encoding, sendingOutputTo: processCodeUnit)

How about `exportingTo`?

-  tempwords.sort(isOrderedBefore: <)
+  tempwords.sort(orderingBy: <)

With `sort` and `sorted`, I'd prefer `by:`

-  if !expected.elementsEqual(actual, isEquivalent: sameValue) {
+  if !expected.elementsEqual(actual, comparingBy: sameValue) {

I'm torn on this one. I don't like but I don't have a good solution.

-  /// for which `predicate(x) == true`.
+  /// for which `isIncluded(x) == true`.
-  _base: base.makeIterator(), whereElementsSatisfy: _include)
+  _base: base.makeIterator(), suchThat: _include)

How about simply `include` for both? I get the `is` desire but it's being 
tossed away
in a lot of other places in this diff. and `suchThat` feels out of place.

-  || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {
+|| u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) }) {

I assume the challenge here is differentiating contains(element) from 
contains(closure).
This feels predicate-y, which is why I put it near the predicates. But I think 
something
like `containsElement(where:)` works better.

 -let result = try base._withUnsafeMutableBufferPointerIfSupported(body)
+let result = try base._withUnsafeMutableBufferPointerIfSupported(invoke: 
body)

I hate "ifSupported" but that's another discussion 
(withSupportedUnsafeMutableBufferPointer,
withAvailableUnsafeMutableBufferPointer, it's all lipstick)

This is procedural, so `do` or `perform` rather than `invoke`

-  for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {
+  for test in removeFirstTests.filter(
+suchThat: { $0.numberToRemove == 1 }

The difference between `filter` and `forEach` is that `forEach` is explicitly 
procedural while `filter` is functional.  I do not like functional chainable
calls being modified to use explicit external labels in this way. 

I'd prefer no label here.

public func split(
  maxSplits: Int = Int.max,
  omittingEmptySubsequences: Bool = true,
-isSeparator: @noescape (Base.Iterator.Element) throws -> Bool
+separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws -> 
Bool

I'm torn on this one. It's not the worst ever but something more like 
where/at/when
makes more sense to me than "separatedWhere/separatedAt/separatedWhen".

+  count: __manager._headerPointer.pointee.count)

For the sake of Zippy the Pinhead, surely there has to be something better than 
`pointee`.
Like...`reference`?

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

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread Matthew Johnson via swift-evolution


>   * What is your evaluation of the proposal?

This looks really great!  Thank you team for all of your hard work on improving 
the numeric protocols in Swift 3.

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

Yes.  The current protocols leave a lot of room for improvement, which we see 
in this proposal.

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

Yes very much so.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I have not.

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

I read the proposal when a draft was available and again tonight.  I have also 
encountered some of the challenges described with the existing protocols.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> 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] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread T.J. Usiyan via swift-evolution

Karl - Absolute value of `Int.min` is currently not representable by an
Int.

On Wed, Jun 22, 2016 at 9:32 PM, Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> Looks very good. A couple of points:
>
> - I’m not convinced about ‘absoluteValue’, with an associated type. I
> think it should return the same value as ‘abs()’ or have a different name
> if it’s really needed at all; the example of a print function is a bit weak
> IMO.
> - I’m not sure about an ‘nthWord()’ getter without a corresponding setter.
> - I would like ‘floor’ and ‘ceil’ to be part of the standard library (or
> some equivalent). It annoys me that I have to import Darwin/Glibc to
> properly convert between standard library types. Would this go with the
> initialisers from FloatingPoint on Integer, or somewhere on FloatingPoint?
>
> Definitely a step up from what we have, and a good foundation to build on.
>
> Karl
>
> > On 23 Jun 2016, at 02:52, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "SE-0104: Protocol-oriented integers" begins now and runs
> through June 27. The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.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 contribute to 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 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,
> >
> > -Chris Lattner
> > 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread Karl via swift-evolution

+1

Looks very good. A couple of points:

- I’m not convinced about ‘absoluteValue’, with an associated type. I think it 
should return the same value as ‘abs()’ or have a different name if it’s really 
needed at all; the example of a print function is a bit weak IMO.
- I’m not sure about an ‘nthWord()’ getter without a corresponding setter.
- I would like ‘floor’ and ‘ceil’ to be part of the standard library (or some 
equivalent). It annoys me that I have to import Darwin/Glibc to properly 
convert between standard library types. Would this go with the initialisers 
from FloatingPoint on Integer, or somewhere on FloatingPoint?

Definitely a step up from what we have, and a good foundation to build on.

Karl

> On 23 Jun 2016, at 02:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0104: Protocol-oriented integers" begins now and runs 
> through June 27. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.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 contribute to 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 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,
> 
> -Chris Lattner
> 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] Partial list of open Swift 3 design topics

2016-06-22 Thread Austin Zheng via swift-evolution

I'd be happy to put together proposals for associated type inference
removal and removing type system significance from argument labels, if
nobody else wants them.

Austin

On Wed, Jun 22, 2016 at 6:16 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi everyone,
>>
>> Here is a partial list of the open topics that the core team would like
>> to get resolved in Swift 3.  The list is partial both because I’m way
>> behind on swift-evolution traffic, but also because new things may come
>> up.  There are also a number of accepted proposals that are not yet
>> implemented.  Some topics have proposals done, and therefore have an SE
>> number, but the review discussion hasn’t finalized.  Some of these topics
>> have an “owner” that is driving or planning to start a discussion on them
>> them, which I’ve listed in square brackets.
>>
>> If you’d like to discuss these topics in particular, please start a new
>> thread specific to them, or contribute to an already-existing thread
>> discussing it.  Several of these don’t have an owner yet, so if you’d like
>> to pick them up and run with them, that would be great.  Thanks!
>>
>> -Chris
>>
>>
>> Language:
>> - SE-0091: Improving operator requirements in protocols [Core team
>> discussed this, will email about it shortly]
>> - SE-0077: Improve operator declaration syntax [Core team discussed this,
>> Joe Groff will follow up on this soon]
>> - SE-0095: Replace protocol syntax with P1 & P2 syntax
>> - SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
>> - SE-0103: Invert @noescape
>> - Remove T -> T? implicit promotion for operands to operators
>> - Removing argument labels from the type system (so they are
>> declaration-only constructs)
>> - Some reshuffling with requiring @objc/@nonobjc for things that
>> shouldn’t/can’t be expressed via the Objective-C runtime
>> - Eliminating inference of associated type witnesses (as is mentioned in
>> the generics manifesto)
>> - Should public classes be non-publicly-subclassable by default? [John
>> McCall]
>> - Revising access modifiers on extensions [Adrian Zubarev]
>>
>>
>> Standard library:
>>  - SE-0101: Rename sizeof and related functions to comply with API
>> Guidelines
>>  - Ongoing API naming adjustments for stdlib:
>> - Closure arguments [Dave Abrahams]
>> - Others are being discussed on swift-evolution.
>>  - Remove Boolean protocol.
>>
> ^^^
> What's the thinking behind this particular item?
>
>
>>  - SE-0104: Revise Integer protocols to match FP ones. [Max Moiseev]
>>
>> SDK / Cocoa / ObjC interop:
>>  - [SE-0086] Finalize NS removal plan. [Tony Parker]
>>  - Importing “id” as Any [Joe Groff]
>>  - Revise NSError/Error model for better interoperability and usability.
>> [Doug Gregor]
>>  -  Bridge NSRange to “Range?”
>>
>> ___
>> 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] Partial list of open Swift 3 design topics

On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everyone,
>
> Here is a partial list of the open topics that the core team would like to
> get resolved in Swift 3.  The list is partial both because I’m way behind
> on swift-evolution traffic, but also because new things may come up.  There
> are also a number of accepted proposals that are not yet implemented.  Some
> topics have proposals done, and therefore have an SE number, but the review
> discussion hasn’t finalized.  Some of these topics have an “owner” that is
> driving or planning to start a discussion on them them, which I’ve listed
> in square brackets.
>
> If you’d like to discuss these topics in particular, please start a new
> thread specific to them, or contribute to an already-existing thread
> discussing it.  Several of these don’t have an owner yet, so if you’d like
> to pick them up and run with them, that would be great.  Thanks!
>
> -Chris
>
>
> Language:
> - SE-0091: Improving operator requirements in protocols [Core team
> discussed this, will email about it shortly]
> - SE-0077: Improve operator declaration syntax [Core team discussed this,
> Joe Groff will follow up on this soon]
> - SE-0095: Replace protocol syntax with P1 & P2 syntax
> - SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
> - SE-0103: Invert @noescape
> - Remove T -> T? implicit promotion for operands to operators
> - Removing argument labels from the type system (so they are
> declaration-only constructs)
> - Some reshuffling with requiring @objc/@nonobjc for things that
> shouldn’t/can’t be expressed via the Objective-C runtime
> - Eliminating inference of associated type witnesses (as is mentioned in
> the generics manifesto)
> - Should public classes be non-publicly-subclassable by default? [John
> McCall]
> - Revising access modifiers on extensions [Adrian Zubarev]
>
>
> Standard library:
>  - SE-0101: Rename sizeof and related functions to comply with API
> Guidelines
>  - Ongoing API naming adjustments for stdlib:
> - Closure arguments [Dave Abrahams]
> - Others are being discussed on swift-evolution.
>  - Remove Boolean protocol.
>
^^^
What's the thinking behind this particular item?


>  - SE-0104: Revise Integer protocols to match FP ones. [Max Moiseev]
>
> SDK / Cocoa / ObjC interop:
>  - [SE-0086] Finalize NS removal plan. [Tony Parker]
>  - Importing “id” as Any [Joe Groff]
>  - Revise NSError/Error model for better interoperability and usability.
> [Doug Gregor]
>  -  Bridge NSRange to “Range?”
>
> ___
> 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] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Matthew Johnson via swift-evolution


> On Jun 22, 2016, at 7:27 PM, Brent Royal-Gordon  
> wrote:
> 
> I think you're tremendously overcomplicating the design.

This isn’t intended as a proposed design.  It is intended to start a discussion 
exploring the design space.

> 
>> If we’re going to consider alternative designs it is worth considering the 
>> semantic space available.  For the sake of discussion, here is a model that 
>> captures the various semantics that exist (the names are just strawmen):
>> 
>>  Iterable 
>>  /  \
>> / \
>>/   \
>>   FiniteIterable MultipassIterable
>>   \ /
>> \  / 
>>  \/
>> Sequence
>>|
>>|
>> Collection
>> 
>> `Iterable` corresponds to the current `Sequence` - no semantics beyond 
>> iteration are required.  Infinite, single-pass “sequences” may conform.  
> 
> Okay, so let's start by undoing that renaming to make clear which semantics 
> in this hierarchy are actually new and which ones are already part of the 
> standard library.
> 
>Sequence 
>  /  \
> / \
>/   \
>   FiniteSequence MultipassSequence
>   \ /
> \  / 
>  \/
>   FiniteMultipassSequence
>|
>|
> Collection

Yes, I should have done it this way to begin with.

> 
>> `for..in` naturally requires `FiniteIterable`,
> 
> Why? There's nothing conceptually incoherent about looping over an infinite 
> sequence. Even ignoring errors, you can `break` out, you can `exit()` from an 
> interior method, you can abort or fail a precondition, or you can just let it 
> loop forever. Forbidding potentially-infinite for loops `for` loops is an 
> arbitrary limitation.

The argument for doing this is that `for..in` is syntactic sugar and looping 
over an infinite sequence using it is often going to be a mistake.  I think 
it’s reasonable to suggest that it be a little be more difficult to write an 
infinite loop in order to prevent one from doing so accidentally.  The position 
you and Dave have taken is also reasonable.

> 
>> but does not require the `MultipassIterable`.
>> 
>> There are many interesting infinite `MultipassIterable` types.  These 
>> include any dynamically generated sequence, such as a mathematical sequence 
>> (even numbers, odd numbers, etc).  This is also what the existing `Sequence` 
>> would become if we drop support for destructive sequences and do nothing 
>> else (note: it would still be possible to accidentally write a `for..in` 
>> loop over an infinite sequence).
> 
> Okay, but all of these can be represented as infinite Collections.
> 
> Let me explain. If a Sequence is truly multipass—that is, you can iterate 
> over it many times and it will always return the same elements—then it must 
> look something like this:
> 
>   struct MyElement { … }  
>   
>   struct MyState {
>   …
>   init() { … }
>   mutating func formNextElement(in: MySequence) { … }
>   var currentElement(in: MySequence) -> MyElement? { … }
>   }
> 
>   struct MySequence: MultipassSequence {
>   struct Iterator: IteratorProtocol {
>   var sequence: MySequence
>   var state: MyState
>   
>   init(sequence: MySequence, initialState: MyState) {
>   self.sequence = sequence
>   self.state = initialState
>   }
>   
>   mutating func next() -> MyElement? {
>   defer { someState.formNextElement(in: sequence) 
> }
>   return someState.currentElement(in: sequence)
>   }
>   }
>   
>   func formIterator() -> MyIterator {
>   return MyIterator(sequence: self, initialState: 
> MyState())
>   }
>   }
> 
> Now, the pieces may *appear* to be different—the Iterator may not actually 
> need a reference to the Sequence, the state may be stored in many properties 
> instead of just one, the code to iterate and get the current element may be 
> directly in `next()` instead of in methods `next()` calls—but any multipass 
> Sequence and Iterator could be refactored to match this pattern, so all 
> multipass Sequences and Iterators are equivalent to

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Matthew Johnson via swift-evolution


> On Jun 22, 2016, at 6:41 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 22 2016, Matthew Johnson  > wrote:
> 
>>> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Wed Jun 22 2016, David Waite  wrote:
>>> 
>> 
 Today, a Sequence differs from a Collection in that:
 
 - A sequence can be infinitely or indefinitely sized, or could require
 an O(n) operation to count the values in the sequence. 
>>> 
>>> The latter being no different from Collection.
>>> 
 A collection has a finite number of elements, and the fixed size is
 exposed as an O(1) or O(n) operation via ‘count’
>>> 
>>> I don't believe we've actually nailed down that Collection is finite.
>>> 
>>> Oh, gee, Nate's documentation edits do
>>> that. (https://github.com/apple/swift/commit/6e274913)
>>> Nate, did we discuss this explicitly or did it slip in unnoticed?
>>> 
>>> The one crucial distinction in Collection is that you can make multiple
>>> passes over the same elements.
>>> 
 - A collection is indexable, with those indices being usable for
 various operations including forming subsets, comparisons, and manual
 iteration
 
 - A sequence may or may not be destructive, where a destructive
 sequence consumes elements during traversal, making them unavailable
 on subsequent traversals. Collection operations are required to be
 non-destructive
 
 I would like to Pitch removing this third differentiation, the option
 for destructive sequences.
>>> 
>>> I have been strongly considering this direction myself, and it's
>>> something we need to decide about for Swift 3.
>> 
>> I believe this is a problem that should be solved.  
>> 
>> I also believe distinguishing between finite and infinite sequences is
>> a good idea (along with preventing for..in from being used with an
>> infinite sequence)
> 
> for..in over an infinite sequence is not necessarily wrong.  I'm not
> confident it should be prevented.  It's certainly less dangerous than
> using `forEach`, from which there is no possibility of escape.

Sure, it’s not wrong in the sense that sometimes an infinite loop is valid.  
But I think it would almost always be wrong (an accident) in practice.  If you 
really want to loop over an infinite sequence maybe it’s a good thing to 
require you to do that explicitly.

> 
 My main motivation for proposing this is the potential for developer
 confusion. As stated during one of the previous threads on the naming
 of map, flatMap, filter, etc. methods on Sequence, Sequence has a
 naming requirement not typical of the rest of the Swift standard
 library in that many methods on Sequence may or may not be
 destructive. As such, naming methods for any extensions on Sequence is
 challenging as the names need to not imply immutability.
>>> 
>>> I don't think the names are really the worst potential cause of
>>> confusion here.  There's also the fact that you can conform to Sequence
>>> with a destructively-traversed “value type” that has no mutating
>>> methods.
>> 
>> I agree, names are not the primary issue.  
>> 
>> Another issue is that you cannot currently write generic code that
>> might need to iterate a sequence more than once.  You currently have
>> to over-constrain types to `Collection` even if you don’t need to do
>> anything other than iterate the elements (the discussion about whether
>> `LazyFilterSequnce` has a bug in its `underestimateCount` is relevant
>> here).
> 
> That's not an over-constraint.  Multi-pass-ness *is* the fundamental
> distinction between Sequence and Collection.  AFAIK there's no multipass
> sequence that cannot support indices.

If we do nail down that Collection has to be finite then this is not the case.  
There are infinite multipass sequences.

If we require Sequence to be multipass (that is the same as removing 
destructive consumption, isn’t it?) then what would be the distinction between 
Sequence and Collection?  The fact that we are making Collection finite?

> 
 It would still be possible to have Generators which operate
>>> 
>>>  “Iterators,” please.
>>> 
 destructively, but such Generators would not conform to the needs of
 Sequence. As such, the most significant impact would be the inability
 to use such Generators in a for..in loop, 
>>> 
>>> Trying to evaluate this statement, it's clear we're missing lots of
>>> detail here:
>>> 
>>> * Would you remove Sequence?
>>> * If so, what Protocol would embody “for...in-able?”
>>> * If not, would you remove Collection?
>>> * What role would Iterator play?
>> 
>> If we’re going to consider alternative designs it is worth considering
>> the semantic space available.  For the sake of discussion, here is a
>> model that captures the various semantics that

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

2016-06-22 Thread Sean Heber via swift-evolution

How about:

let results = possibilities.where(matching: closure)

:)

l8r
Sean 

Sent from my iPad

> On Jun 22, 2016, at 8:00 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> filter(extractingWhere:)
>> On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Wed Jun 22 2016, Xiaodi Wu  wrote:
>> 
>> > I'll duly oblige with some pushback on `suchThat`. I get that you're trying
>> > to clarify whether filter retains or gets rid of elements that match the
>> > predicate, but I don't think "filter such that" expresses this idea at all.
>> >
>> > Comparing to "filter where," "filter such that" is equally susceptible to
>> > misinterpretation that you are filtering to remove elements that are
>> > matched. For example: "find me some apples, filtering such that are
>> > bruised."
>> 
>> Hahaha, that's a very different interpretation of “such” that I hadn't
>> considered!  OK, suppose it was “soEach:” ?
>> 
>> let primes = xs.filter(soEach: isPrime)
>> 
>> > I'd suggest that if you want to be perfectly clear, you'd need something
>> > like `filter(keepingWhere:)`.
>> 
>> let primes = xs.filter(keepingWhere: isPrime)
>> 
>> A slight problem is that filter is nonmutating, so all elements are
>> “kept.”  But maybe that's just Dave being overly concerned with unlikely
>> misinterpretations at the cost of “naturalness.”
>> 
>> Further thoughts?
>> 
>> > On Wed, Jun 22, 2016 at 18:33 Dave Abrahams via swift-evolution <
>> > swift-evolution@swift.org> wrote:
>> >
>> >>
>> >> on Tue Jun 21 2016, Dave Abrahams  wrote:
>> >>
>> >> > on Mon Jun 20 2016, Brent Royal-Gordon 
>> >> wrote:
>> >> >
>> >> >>> A couple of weeks ago we started to notice that we had some
>> >> poorly-named
>> >> >>> closure parameters and argument labels in the standard library, so we
>> >> >>> did a complete audit of the standard library's APIs and came up with a
>> >> >>> preliminary proposal for changes, which we applied in a branch and you
>> >> >>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>> >> >>> carry on further discussion here rather than in the pull request,
>> >> though.
>> >> >>
>> >> >> In general, I like this; `orderingBy` is a particularly nice
>> >> >> improvement over the old `isOrderedBefore` convention.
>> >> >
>> >> > I don't really love the use of “by”, FWIW, but I thought `orderingWith`
>> >> > was more confusable (ordering A with B might swap A and B, whereas the
>> >> > parameter is a closure).  It could be argued, though, that I am being
>> >> > overly concerned with unlikely misinterpretations, at the cost of
>> >> > “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open to
>> >> > discussion on this.
>> >> >
>> >> >> A few specific comments about things I don't like:
>> >> >>
>> >> >> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
>> >> >>   over `elementTransform`.
>> >> >
>> >> > I think you mean the converse.  And I agree that `elementTransform`
>> >> > is probably not an improvement over `transform`.
>> >>
>> >> ...and I've gone back to `transform` in my PR.
>> >>
>> >> >> * In general, I'm not a fan of most of the changes away from `where`
>> >> >> labels.
>> >> >
>> >> > The only such changes I can find are in
>> >> >
>> >> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
>> >> >
>> >> > Note that part of this change was to make all filter closures
>> >> > consistent; in the main `filter` API there was no label at all.
>> >> > However, we felt that there's a real clarity problem with the polarity
>> >> > of the argument (we talk about “filtering things out” but the closure
>> >> > indicates which elements to keep).  And we couldn't find a “where”-based
>> >> > name that began to clarify it.
>> >> >
>> >> > I will argue that even changing to “suchThat,” as in the PR, does not
>> >> > sufficiently clarify the closure's polarity, and the only true fix for
>> >> > filter is to use a different base name (some have suggested “select,”
>> >> > and I have other ideas), but that is out of scope for this particular
>> >> > set of changes.  So if the community is happier with a “where” label
>> >> > here I can live with it.  I do think “suchThat” is marginally clearer.
>> >>
>> >> I have not received any further pushback on “suchThat,” so I've left it
>> >> alone.
>> >>
>> >> >
>> >> >> Those are a nice, straightforward convention applied broadly across
>> >> >> the Sequence APIs. (Yes, I criticized `where` as a method name in
>> >> >> another thread, but I don't think `where` is a problem when there's a
>> >> >> function base name to give it context.) When they don't work, that's
>> >> >> usually because of a less-than-ideal base name. I'm not saying that
>> >> >> *all* base names that aren't compatible with `where` should be
>> >> >> changed, but

[swift-evolution] Partial list of open Swift 3 design topics

2016-06-22 Thread Chris Lattner via swift-evolution

Hi everyone,

Here is a partial list of the open topics that the core team would like to get 
resolved in Swift 3.  The list is partial both because I’m way behind on 
swift-evolution traffic, but also because new things may come up.  There are 
also a number of accepted proposals that are not yet implemented.  Some topics 
have proposals done, and therefore have an SE number, but the review discussion 
hasn’t finalized.  Some of these topics have an “owner” that is driving or 
planning to start a discussion on them them, which I’ve listed in square 
brackets. 

If you’d like to discuss these topics in particular, please start a new thread 
specific to them, or contribute to an already-existing thread discussing it.  
Several of these don’t have an owner yet, so if you’d like to pick them up and 
run with them, that would be great.  Thanks!

-Chris


Language:
- SE-0091: Improving operator requirements in protocols [Core team discussed 
this, will email about it shortly]
- SE-0077: Improve operator declaration syntax [Core team discussed this, Joe 
Groff will follow up on this soon]
- SE-0095: Replace protocol syntax with P1 & P2 syntax
- SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type
- SE-0103: Invert @noescape
- Remove T -> T? implicit promotion for operands to operators
- Removing argument labels from the type system (so they are declaration-only 
constructs)
- Some reshuffling with requiring @objc/@nonobjc for things that 
shouldn’t/can’t be expressed via the Objective-C runtime
- Eliminating inference of associated type witnesses (as is mentioned in the 
generics manifesto)
- Should public classes be non-publicly-subclassable by default? [John McCall]
- Revising access modifiers on extensions [Adrian Zubarev]


Standard library:
 - SE-0101: Rename sizeof and related functions to comply with API Guidelines
 - Ongoing API naming adjustments for stdlib:
- Closure arguments [Dave Abrahams]
- Others are being discussed on swift-evolution.
 - Remove Boolean protocol.
 - SE-0104: Revise Integer protocols to match FP ones. [Max Moiseev]

SDK / Cocoa / ObjC interop:
 - [SE-0086] Finalize NS removal plan. [Tony Parker]
 - Importing “id” as Any [Joe Groff]
 - Revise NSError/Error model for better interoperability and usability. [Doug 
Gregor]
 -  Bridge NSRange to “Range?”

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

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

2016-06-22 Thread Brent Royal-Gordon via swift-evolution

filter(extractingWhere:)
On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Jun 22 2016, Xiaodi Wu  wrote:
>
> > I'll duly oblige with some pushback on `suchThat`. I get that you're
> trying
> > to clarify whether filter retains or gets rid of elements that match the
> > predicate, but I don't think "filter such that" expresses this idea at
> all.
> >
> > Comparing to "filter where," "filter such that" is equally susceptible to
> > misinterpretation that you are filtering to remove elements that are
> > matched. For example: "find me some apples, filtering such that are
> > bruised."
>
> Hahaha, that's a very different interpretation of “such” that I hadn't
> considered!  OK, suppose it was “soEach:” ?
>
> let primes = xs.filter(soEach: isPrime)
>
> > I'd suggest that if you want to be perfectly clear, you'd need something
> > like `filter(keepingWhere:)`.
>
> let primes = xs.filter(keepingWhere: isPrime)
>
> A slight problem is that filter is nonmutating, so all elements are
> “kept.”  But maybe that's just Dave being overly concerned with unlikely
> misinterpretations at the cost of “naturalness.”
>
> Further thoughts?
>
> > On Wed, Jun 22, 2016 at 18:33 Dave Abrahams via swift-evolution <
> > swift-evolution@swift.org> wrote:
> >
> >>
> >> on Tue Jun 21 2016, Dave Abrahams  wrote:
> >>
> >> > on Mon Jun 20 2016, Brent Royal-Gordon 
> >> wrote:
> >> >
> >> >>> A couple of weeks ago we started to notice that we had some
> >> poorly-named
> >> >>> closure parameters and argument labels in the standard library, so
> we
> >> >>> did a complete audit of the standard library's APIs and came up
> with a
> >> >>> preliminary proposal for changes, which we applied in a branch and
> you
> >> >>> can review in https://github.com/apple/swift/pull/2981.  Let's
> please
> >> >>> carry on further discussion here rather than in the pull request,
> >> though.
> >> >>
> >> >> In general, I like this; `orderingBy` is a particularly nice
> >> >> improvement over the old `isOrderedBefore` convention.
> >> >
> >> > I don't really love the use of “by”, FWIW, but I thought
> `orderingWith`
> >> > was more confusable (ordering A with B might swap A and B, whereas the
> >> > parameter is a closure).  It could be argued, though, that I am being
> >> > overly concerned with unlikely misinterpretations, at the cost of
> >> > “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open
> to
> >> > discussion on this.
> >> >
> >> >> A few specific comments about things I don't like:
> >> >>
> >> >> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
> >> >>   over `elementTransform`.
> >> >
> >> > I think you mean the converse.  And I agree that `elementTransform`
> >> > is probably not an improvement over `transform`.
> >>
> >> ...and I've gone back to `transform` in my PR.
> >>
> >> >> * In general, I'm not a fan of most of the changes away from `where`
> >> >> labels.
> >> >
> >> > The only such changes I can find are in
> >> >
> >>
> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
> >> >
> >> > Note that part of this change was to make all filter closures
> >> > consistent; in the main `filter` API there was no label at all.
> >> > However, we felt that there's a real clarity problem with the polarity
> >> > of the argument (we talk about “filtering things out” but the closure
> >> > indicates which elements to keep).  And we couldn't find a
> “where”-based
> >> > name that began to clarify it.
> >> >
> >> > I will argue that even changing to “suchThat,” as in the PR, does not
> >> > sufficiently clarify the closure's polarity, and the only true fix for
> >> > filter is to use a different base name (some have suggested “select,”
> >> > and I have other ideas), but that is out of scope for this particular
> >> > set of changes.  So if the community is happier with a “where” label
> >> > here I can live with it.  I do think “suchThat” is marginally clearer.
> >>
> >> I have not received any further pushback on “suchThat,” so I've left it
> >> alone.
> >>
> >> >
> >> >> Those are a nice, straightforward convention applied broadly across
> >> >> the Sequence APIs. (Yes, I criticized `where` as a method name in
> >> >> another thread, but I don't think `where` is a problem when there's a
> >> >> function base name to give it context.) When they don't work, that's
> >> >> usually because of a less-than-ideal base name. I'm not saying that
> >> >> *all* base names that aren't compatible with `where` should be
> >> >> changed, but rather that if `where` is not enough, that's an API
> >> >> smell.
> >> >>
> >> >> * In particular, `elementWhere` is not a good label for the same
> >> >> reason that `removeElement` is not a good name. Session 403 last week
> >> >> actually talked about this between roughly minutes 8 and 11. (I'm

[swift-evolution] [Review] SE-0104: Protocol-oriented integers

2016-06-22 Thread Chris Lattner via swift-evolution

Hello Swift community,

The review of "SE-0104: Protocol-oriented integers" begins now and runs through 
June 27. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.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 contribute to 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 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,

-Chris Lattner
Review Manager


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

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

2016-06-22 Thread Brandon Knope via swift-evolution

Isn't this more caused by confusion about how infinite sequences work?

The prefix one is no longer an infinite sequence. The second one still is. The 
second one will always infinite loop unless you break

Brandon

Sent from my iPad

> On Jun 22, 2016, at 5:28 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> As you will see from earlier messages, the confused user is both quite real 
>> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
>> trivialized; they are serious concerns for the design of the language. On 
>> what grounds do you assert that something is "not confusing at all" when 
>> there has been testimony saying "it was confusing to me"?
>> 
>> Some of us on this list interact regularly with novice coders. I draw upon 
>> these experiences here. Do you have some special insight you'd like to share 
>> in that regard?
>>> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  wrote:
>>> How about the goal of it being a delightful language to program in. I think 
>>> that is getting lost in proposals like these. Optimizing for some mythical 
>>> new user, who really isn’t present on this list to give an opinion seems 
>>> like a false argument to make, and your technical sophistication makes you 
>>> a less qualified than most to say what is and what isn’t confusing to new 
>>> users because you haven’t been one in a long time.
>>> 
>>> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There 
>>> are far more confusing aspects to the language than this.
>>> 
>>> Cheers
> 
> Yet another case from a few minutes ago:
> 
> [3:08pm] rullie: hi, could someone walk me through this 
> http://pastie.org/10887040
> [3:08pm] rullie: why is it that for loop through an lazy infinite sequence 
> does not terminate even with the where clause invovled?
> [3:08pm] mikeash: "where" means "skip iterations when this condition is not 
> true"
> [3:08pm] mikeash: it doesn't mean "halt the loop when this is not true"
> [3:08pm] rullie: oh whoa.. ok
> [3:09pm] mikeash: it can't know that you'll never see another value < 100, so 
> it keeps on going
> [3:09pm] rullie: ok, i completely misunderstood the where clause then
> [3:10pm] mikeash: I can see how it might look like it does that
> [3:10pm] rullie: is there a syntax that achieves what i want to do without 
> having to have a if-break in the loop?
> 
> 
> -- E
> p.s. Posted with permission from both participants
> 
> ___
> 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] Revisiting SE-0041 Names

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 4:43 PM, Matthew Johnson  wrote:
>
> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko  wrote:
> protocol _IntegerLiteralSyntax {}
> enum Syntax {
>  typealias IntegerLiteral = _IntegerLiteralSyntax
> }
>
> And used like this:
>
> struct Int : Syntax.IntegerLiteral {}
>
>
> Is anyone on the core team planning to write up a proposal for this change?

Your help would be most appreciated!

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris  wrote:
> That's a really interesting idea. Is "Syntax" a placeholder, or is that the 
> intended name?

It is the best name we could come up with, we are open to better suggestions.

> Also, why an enum? Especially one without any cases...

It is not possible to create an instance of an enum that does not have
cases.  It becomes essentially a namespace.

> Was all this already discussed in a thread that I missed (or have otherwise 
> forgotten about)?

This feedback was provided in one of the threads about SE-0041, but I
can't find the link.  It did not get much discussion at that time.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

I think you're tremendously overcomplicating the design.

> If we’re going to consider alternative designs it is worth considering the 
> semantic space available.  For the sake of discussion, here is a model that 
> captures the various semantics that exist (the names are just strawmen):
> 
>   Iterable 
>   /  \
>  / \
> /   \
>FiniteIterable MultipassIterable
>\ /
>  \  / 
>   \/
>  Sequence
> |
> |
>  Collection
> 
> `Iterable` corresponds to the current `Sequence` - no semantics beyond 
> iteration are required.  Infinite, single-pass “sequences” may conform.  

Okay, so let's start by undoing that renaming to make clear which semantics in 
this hierarchy are actually new and which ones are already part of the standard 
library.

Sequence 
  /  \
 / \
/   \
   FiniteSequence MultipassSequence
   \ /
 \  / 
  \/
   FiniteMultipassSequence
|
|
 Collection

> `for..in` naturally requires `FiniteIterable`,

Why? There's nothing conceptually incoherent about looping over an infinite 
sequence. Even ignoring errors, you can `break` out, you can `exit()` from an 
interior method, you can abort or fail a precondition, or you can just let it 
loop forever. Forbidding potentially-infinite for loops `for` loops is an 
arbitrary limitation.

> but does not require the `MultipassIterable`.
> 
> There are many interesting infinite `MultipassIterable` types.  These include 
> any dynamically generated sequence, such as a mathematical sequence (even 
> numbers, odd numbers, etc).  This is also what the existing `Sequence` would 
> become if we drop support for destructive sequences and do nothing else 
> (note: it would still be possible to accidentally write a `for..in` loop over 
> an infinite sequence).

Okay, but all of these can be represented as infinite Collections.

Let me explain. If a Sequence is truly multipass—that is, you can iterate over 
it many times and it will always return the same elements—then it must look 
something like this:

struct MyElement { … }  

struct MyState {
…
init() { … }
mutating func formNextElement(in: MySequence) { … }
var currentElement(in: MySequence) -> MyElement? { … }
}

struct MySequence: MultipassSequence {
struct Iterator: IteratorProtocol {
var sequence: MySequence
var state: MyState

init(sequence: MySequence, initialState: MyState) {
self.sequence = sequence
self.state = initialState
}

mutating func next() -> MyElement? {
defer { someState.formNextElement(in: sequence) 
}
return someState.currentElement(in: sequence)
}
}

func formIterator() -> MyIterator {
return MyIterator(sequence: self, initialState: 
MyState())
}
}

Now, the pieces may *appear* to be different—the Iterator may not actually need 
a reference to the Sequence, the state may be stored in many properties instead 
of just one, the code to iterate and get the current element may be directly in 
`next()` instead of in methods `next()` calls—but any multipass Sequence and 
Iterator could be refactored to match this pattern, so all multipass Sequences 
and Iterators are equivalent to it.

But you can convert MySequence into a possibly infinite MyCollection like so:

struct MyCollection: PossiblyInfiniteCollection {
enum Index: Comparable {
var offset: Int
var state: MyState?
}

var startIndex: Index {
return Index(offset: 0, state: MyState())
}
var endIndex: Index {
return Index(offset: Int.max, state: nil)
}

func formIndex(after index: inout Index) {
index.state!.formNextElement(in: self)

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread David Sweeris via swift-evolution

That's a really interesting idea. Is "Syntax" a placeholder, or is that the 
intended name? Also, why an enum? Especially one without any cases...

Was all this already discussed in a thread that I missed (or have otherwise 
forgotten about)?

- Dave Sweeris

Sent from my iPhone

> On Jun 22, 2016, at 15:54, Dmitri Gribenko  wrote:
> 
>> On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris  wrote:
>> 
>>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution 
>>>  wrote:
>>> 
>>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>>>  wrote:
>>> 
>>> Hi Erica,
>>> 
>>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
>>> and me from the last time this was discussed.  Unfortunately I can't
>>> find the exact email, so I can't provide a link.
>>> 
>>> - The "literal" protocols are not about conversion, they are about
>>> adopting a certain syntax provided by the language.  "Convertible" in
>>> the name is a red herring: a type can't be convertible from an integer
>>> literal because there is no "IntegerLiteral" entity in the type
>>> system.  The literal *becomes* typed as the corresponding literal type
>>> (e.g., Int or String), and as far as the user at the call site is
>>> concerned, there is no visible conversion (even if one is happening
>>> behind the scenes).
>>> 
>>> Our suggestion was to focus on the "adopting the syntax" part.  We
>>> suggested moving the "literal convertible" protocols into a
>>> pseudo-namespace "Syntax".  It could be implemented like this:
>>> 
>>> protocol _IntegerLiteralSyntax {}
>>> enum Syntax {
>>> typealias IntegerLiteral = _IntegerLiteralSyntax
>>> }
>>> 
>>> And used like this:
>>> 
>>> struct Int : Syntax.IntegerLiteral {}
>>> 
>>> - For protocols that are representing conversions between types that
>>> actually exist in the library, there is not enough precedent yet to
>>> make a general conclusion and standardize a pattern.
>> 
>> I’m not sure I understand… In this example, has “IntegerLiteralConvertible” 
>> been renamed to “_IntegerLiteralSyntax”?
> 
> That's right.  But we want users to refer to the protocol as
> 'Syntax.IntegerLiteral'.  If/once we get either submodules or
> protocols nested in enums, we can move the actual definition to be
> nested.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Matthew Johnson  wrote:

>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko  wrote:
>> 
>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>> > >
>
>> wrote:
>>> Proposal:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>> 
>>> Rejection: "The feedback on the proposal was generally positive about the
>>> idea of renaming these protocols, but the specific names in the proposal are
>>> not well received, and there is no apparent confluence in the community on
>>> better names.  The core team prefers discussion to continue -- if/when there
>>> is a strong proposal for a better naming approach, we can reconsider
>>> renaming these."
>>> 
>>> John McCall: "To be clear, I don't care about the name.  If you want to
>>> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
>>> the conversation into the muck again. :)  It's the design of the
>>> requirements that I'm pretty opposed to revisiting."
>>> 
>>> The Problem: This is really the last chance to rationalize this across the
>>> language and to evaluate whether other protocol groups should have a core
>>> scheme for naming.
>> 
>> Hi Erica,
>> 
>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
>> and me from the last time this was discussed.  Unfortunately I can't
>> find the exact email, so I can't provide a link.
>> 
>> - The "literal" protocols are not about conversion, they are about
>> adopting a certain syntax provided by the language.  "Convertible" in
>> the name is a red herring: a type can't be convertible from an integer
>> literal because there is no "IntegerLiteral" entity in the type
>> system.  The literal *becomes* typed as the corresponding literal type
>> (e.g., Int or String), and as far as the user at the call site is
>> concerned, there is no visible conversion (even if one is happening
>> behind the scenes).
>> 
>> Our suggestion was to focus on the "adopting the syntax" part.  We
>> suggested moving the "literal convertible" protocols into a
>> pseudo-namespace "Syntax".  It could be implemented like this:
>> 
>> protocol _IntegerLiteralSyntax {}
>> enum Syntax {
>>  typealias IntegerLiteral = _IntegerLiteralSyntax
>> }
>> 
>> And used like this:
>> 
>> struct Int : Syntax.IntegerLiteral {}
>
> Is anyone on the core team planning to write up a proposal for this
> change?  

Not currently.

> If not, I will be happy to do it.  

That's much appreciated!

> It solves the biggest issue I have with the current state (two
> different meanings for “Convertible”).  I will be happy to see this
> solved while we’re making breaking changes. :)
>
>> 
>> - For protocols that are representing conversions between types that
>> actually exist in the library, there is not enough precedent yet to
>> make a general conclusion and standardize a pattern.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko
>> > >*/
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave

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

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

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Xiaodi Wu  wrote:

> I'll duly oblige with some pushback on `suchThat`. I get that you're trying
> to clarify whether filter retains or gets rid of elements that match the
> predicate, but I don't think "filter such that" expresses this idea at all.
>
> Comparing to "filter where," "filter such that" is equally susceptible to
> misinterpretation that you are filtering to remove elements that are
> matched. For example: "find me some apples, filtering such that are
> bruised."

Hahaha, that's a very different interpretation of “such” that I hadn't
considered!  OK, suppose it was “soEach:” ?

let primes = xs.filter(soEach: isPrime)

> I'd suggest that if you want to be perfectly clear, you'd need something
> like `filter(keepingWhere:)`.

let primes = xs.filter(keepingWhere: isPrime)

A slight problem is that filter is nonmutating, so all elements are
“kept.”  But maybe that's just Dave being overly concerned with unlikely
misinterpretations at the cost of “naturalness.”

Further thoughts?

> On Wed, Jun 22, 2016 at 18:33 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Tue Jun 21 2016, Dave Abrahams  wrote:
>>
>> > on Mon Jun 20 2016, Brent Royal-Gordon 
>> wrote:
>> >
>> >>> A couple of weeks ago we started to notice that we had some
>> poorly-named
>> >>> closure parameters and argument labels in the standard library, so we
>> >>> did a complete audit of the standard library's APIs and came up with a
>> >>> preliminary proposal for changes, which we applied in a branch and you
>> >>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>> >>> carry on further discussion here rather than in the pull request,
>> though.
>> >>
>> >> In general, I like this; `orderingBy` is a particularly nice
>> >> improvement over the old `isOrderedBefore` convention.
>> >
>> > I don't really love the use of “by”, FWIW, but I thought `orderingWith`
>> > was more confusable (ordering A with B might swap A and B, whereas the
>> > parameter is a closure).  It could be argued, though, that I am being
>> > overly concerned with unlikely misinterpretations, at the cost of
>> > “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open to
>> > discussion on this.
>> >
>> >> A few specific comments about things I don't like:
>> >>
>> >> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
>> >>   over `elementTransform`.
>> >
>> > I think you mean the converse.  And I agree that `elementTransform`
>> > is probably not an improvement over `transform`.
>>
>> ...and I've gone back to `transform` in my PR.
>>
>> >> * In general, I'm not a fan of most of the changes away from `where`
>> >> labels.
>> >
>> > The only such changes I can find are in
>> >
>> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
>> >
>> > Note that part of this change was to make all filter closures
>> > consistent; in the main `filter` API there was no label at all.
>> > However, we felt that there's a real clarity problem with the polarity
>> > of the argument (we talk about “filtering things out” but the closure
>> > indicates which elements to keep).  And we couldn't find a “where”-based
>> > name that began to clarify it.
>> >
>> > I will argue that even changing to “suchThat,” as in the PR, does not
>> > sufficiently clarify the closure's polarity, and the only true fix for
>> > filter is to use a different base name (some have suggested “select,”
>> > and I have other ideas), but that is out of scope for this particular
>> > set of changes.  So if the community is happier with a “where” label
>> > here I can live with it.  I do think “suchThat” is marginally clearer.
>>
>> I have not received any further pushback on “suchThat,” so I've left it
>> alone.
>>
>> >
>> >> Those are a nice, straightforward convention applied broadly across
>> >> the Sequence APIs. (Yes, I criticized `where` as a method name in
>> >> another thread, but I don't think `where` is a problem when there's a
>> >> function base name to give it context.) When they don't work, that's
>> >> usually because of a less-than-ideal base name. I'm not saying that
>> >> *all* base names that aren't compatible with `where` should be
>> >> changed, but rather that if `where` is not enough, that's an API
>> >> smell.
>> >>
>> >> * In particular, `elementWhere` is not a good label for the same
>> >> reason that `removeElement` is not a good name. Session 403 last week
>> >> actually talked about this between roughly minutes 8 and 11. (I'm sure
>> >> you know about its content; you probably saw it before we did.)
>> >
>> > Yes I do, and I think you misinterpreted the message in that session.
>> > There's nothing wrong with repeating type information when it's
>> > necessary for clarity or fluency at the use-site.  In the case of
>> > `contains(elementWhere:)`, it's there for

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

2016-06-22 Thread Dany St-Amant via swift-evolution


> Le 22 juin 2016 à 12:27, Brandon Knope via swift-evolution 
>  a écrit :
> 
> I really don’t understand why we are wasting everyone’s time debating this.
> 
> Yes I think there is a correlation. Yes this is precisely why I posted the 
> heat map.
> 
> Of course \ is not needed a lot, but when it is, *it is inconvenient for 
> *some* people*. I am not making this up. You can cite several other users 
> from this very thread.
> 
> I tried showing that it is quite distant on the keyboard from where the 
> user’s hands rest. I tried showing that there are other keys at their finger 
> tips where their hand is usually resting.
> 
> 1. Do I know every international keyboard layout? No.
> 2. Are we pretending that \ was picked because it was easier for 
> international users? If I am wrong, I would love to hear more…else let’s not 
> pretend that \ was the optimal key for all.

The same that a good sentinel value is one that is invalid. A good escape 
character is one that is rarely used. If as suggested $() or @() is used, one 
would have, unless extra look ahead magic is added to the parser, would have to 
write string like "0.99\$" and "swift-evolution\@swift.org"; that's assuming 
only \() is changed and not all escaping. Using @ or $ for all escaping is so 
ugly to me, that I cannot write an sample of what it would look like.

One could of course argue that the look ahead is tiny, but escaping in the rare 
case that "$(" need to be displayed one would have to use "\$("; so some $ need 
escaping, whic can be seen as inconsistent and confusing.

So sticking to '\' looks like a good idea.

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

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Matthew Johnson via swift-evolution


> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko  wrote:
> 
> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
> > wrote:
>> Proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>> 
>> Rejection: "The feedback on the proposal was generally positive about the
>> idea of renaming these protocols, but the specific names in the proposal are
>> not well received, and there is no apparent confluence in the community on
>> better names.  The core team prefers discussion to continue -- if/when there
>> is a strong proposal for a better naming approach, we can reconsider
>> renaming these."
>> 
>> John McCall: "To be clear, I don't care about the name.  If you want to
>> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
>> the conversation into the muck again. :)  It's the design of the
>> requirements that I'm pretty opposed to revisiting."
>> 
>> The Problem: This is really the last chance to rationalize this across the
>> language and to evaluate whether other protocol groups should have a core
>> scheme for naming.
> 
> Hi Erica,
> 
> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
> and me from the last time this was discussed.  Unfortunately I can't
> find the exact email, so I can't provide a link.
> 
> - The "literal" protocols are not about conversion, they are about
> adopting a certain syntax provided by the language.  "Convertible" in
> the name is a red herring: a type can't be convertible from an integer
> literal because there is no "IntegerLiteral" entity in the type
> system.  The literal *becomes* typed as the corresponding literal type
> (e.g., Int or String), and as far as the user at the call site is
> concerned, there is no visible conversion (even if one is happening
> behind the scenes).
> 
> Our suggestion was to focus on the "adopting the syntax" part.  We
> suggested moving the "literal convertible" protocols into a
> pseudo-namespace "Syntax".  It could be implemented like this:
> 
> protocol _IntegerLiteralSyntax {}
> enum Syntax {
>  typealias IntegerLiteral = _IntegerLiteralSyntax
> }
> 
> And used like this:
> 
> struct Int : Syntax.IntegerLiteral {}

Is anyone on the core team planning to write up a proposal for this change?  If 
not, I will be happy to do it.  It solves the biggest issue I have with the 
current state (two different meanings for “Convertible”).  I will be happy to 
see this solved while we’re making breaking changes. :)

> 
> - For protocols that are representing conversions between types that
> actually exist in the library, there is not enough precedent yet to
> make a general conclusion and standardize a pattern.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Matthew Johnson  wrote:

>> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 22 2016, David Waite  wrote:
>> 
>
>>> Today, a Sequence differs from a Collection in that:
>>> 
>>> - A sequence can be infinitely or indefinitely sized, or could require
>>> an O(n) operation to count the values in the sequence. 
>> 
>> The latter being no different from Collection.
>> 
>>> A collection has a finite number of elements, and the fixed size is
>>> exposed as an O(1) or O(n) operation via ‘count’
>> 
>> I don't believe we've actually nailed down that Collection is finite.
>> 
>> Oh, gee, Nate's documentation edits do
>> that. (https://github.com/apple/swift/commit/6e274913)
>> Nate, did we discuss this explicitly or did it slip in unnoticed?
>> 
>> The one crucial distinction in Collection is that you can make multiple
>> passes over the same elements.
>> 
>>> - A collection is indexable, with those indices being usable for
>>> various operations including forming subsets, comparisons, and manual
>>> iteration
>>> 
>>> - A sequence may or may not be destructive, where a destructive
>>> sequence consumes elements during traversal, making them unavailable
>>> on subsequent traversals. Collection operations are required to be
>>> non-destructive
>>> 
>>> I would like to Pitch removing this third differentiation, the option
>>> for destructive sequences.
>> 
>> I have been strongly considering this direction myself, and it's
>> something we need to decide about for Swift 3.
>
> I believe this is a problem that should be solved.  
>
> I also believe distinguishing between finite and infinite sequences is
> a good idea (along with preventing for..in from being used with an
> infinite sequence)

for..in over an infinite sequence is not necessarily wrong.  I'm not
confident it should be prevented.  It's certainly less dangerous than
using `forEach`, from which there is no possibility of escape.

>>> My main motivation for proposing this is the potential for developer
>>> confusion. As stated during one of the previous threads on the naming
>>> of map, flatMap, filter, etc. methods on Sequence, Sequence has a
>>> naming requirement not typical of the rest of the Swift standard
>>> library in that many methods on Sequence may or may not be
>>> destructive. As such, naming methods for any extensions on Sequence is
>>> challenging as the names need to not imply immutability.
>> 
>> I don't think the names are really the worst potential cause of
>> confusion here.  There's also the fact that you can conform to Sequence
>> with a destructively-traversed “value type” that has no mutating
>> methods.
>
> I agree, names are not the primary issue.  
>
> Another issue is that you cannot currently write generic code that
> might need to iterate a sequence more than once.  You currently have
> to over-constrain types to `Collection` even if you don’t need to do
> anything other than iterate the elements (the discussion about whether
> `LazyFilterSequnce` has a bug in its `underestimateCount` is relevant
> here).

That's not an over-constraint.  Multi-pass-ness *is* the fundamental
distinction between Sequence and Collection.  AFAIK there's no multipass
sequence that cannot support indices.

>>> It would still be possible to have Generators which operate
>> 
>>  “Iterators,” please.
>> 
>>> destructively, but such Generators would not conform to the needs of
>>> Sequence. As such, the most significant impact would be the inability
>>> to use such Generators in a for..in loop, 
>> 
>> Trying to evaluate this statement, it's clear we're missing lots of
>> detail here:
>> 
>> * Would you remove Sequence?
>> * If so, what Protocol would embody “for...in-able?”
>> * If not, would you remove Collection?
>> * What role would Iterator play?
>
> If we’re going to consider alternative designs it is worth considering
> the semantic space available.  For the sake of discussion, here is a
> model that captures the various semantics that exist (the names are
> just strawmen):
>
>Iterable 
>/  \
>   / \
>  /   \
> FiniteIterable MultipassIterable
> \ /
>   \  / 
>\/
>   Sequence
>  |
>  |
>   Collection
>
> `Iterable` corresponds to the current `Sequence` - no semantics beyond
> iteration are required.  Infinite, single-pass “sequences” may
> conform.

Just to keep things straight, let's please adjust one thing at a time.
Adding new concepts should be separated from renaming existing ones.  I
don't want to have to qualify

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

2016-06-22 Thread Brent Royal-Gordon via swift-evolution

I'll duly oblige with some pushback on `suchThat`. I get that you're trying
to clarify whether filter retains or gets rid of elements that match the
predicate, but I don't think "filter such that" expresses this idea at all.

Comparing to "filter where," "filter such that" is equally susceptible to
misinterpretation that you are filtering to remove elements that are
matched. For example: "find me some apples, filtering such that are
bruised."

I'd suggest that if you want to be perfectly clear, you'd need something
like `filter(keepingWhere:)`.
On Wed, Jun 22, 2016 at 18:33 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Jun 21 2016, Dave Abrahams  wrote:
>
> > on Mon Jun 20 2016, Brent Royal-Gordon 
> wrote:
> >
> >>> A couple of weeks ago we started to notice that we had some
> poorly-named
> >>> closure parameters and argument labels in the standard library, so we
> >>> did a complete audit of the standard library's APIs and came up with a
> >>> preliminary proposal for changes, which we applied in a branch and you
> >>> can review in https://github.com/apple/swift/pull/2981.  Let's please
> >>> carry on further discussion here rather than in the pull request,
> though.
> >>
> >> In general, I like this; `orderingBy` is a particularly nice
> >> improvement over the old `isOrderedBefore` convention.
> >
> > I don't really love the use of “by”, FWIW, but I thought `orderingWith`
> > was more confusable (ordering A with B might swap A and B, whereas the
> > parameter is a closure).  It could be argued, though, that I am being
> > overly concerned with unlikely misinterpretations, at the cost of
> > “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open to
> > discussion on this.
> >
> >> A few specific comments about things I don't like:
> >>
> >> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
> >>   over `elementTransform`.
> >
> > I think you mean the converse.  And I agree that `elementTransform`
> > is probably not an improvement over `transform`.
>
> ...and I've gone back to `transform` in my PR.
>
> >> * In general, I'm not a fan of most of the changes away from `where`
> >> labels.
> >
> > The only such changes I can find are in
> >
> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
> >
> > Note that part of this change was to make all filter closures
> > consistent; in the main `filter` API there was no label at all.
> > However, we felt that there's a real clarity problem with the polarity
> > of the argument (we talk about “filtering things out” but the closure
> > indicates which elements to keep).  And we couldn't find a “where”-based
> > name that began to clarify it.
> >
> > I will argue that even changing to “suchThat,” as in the PR, does not
> > sufficiently clarify the closure's polarity, and the only true fix for
> > filter is to use a different base name (some have suggested “select,”
> > and I have other ideas), but that is out of scope for this particular
> > set of changes.  So if the community is happier with a “where” label
> > here I can live with it.  I do think “suchThat” is marginally clearer.
>
> I have not received any further pushback on “suchThat,” so I've left it
> alone.
>
> >
> >> Those are a nice, straightforward convention applied broadly across
> >> the Sequence APIs. (Yes, I criticized `where` as a method name in
> >> another thread, but I don't think `where` is a problem when there's a
> >> function base name to give it context.) When they don't work, that's
> >> usually because of a less-than-ideal base name. I'm not saying that
> >> *all* base names that aren't compatible with `where` should be
> >> changed, but rather that if `where` is not enough, that's an API
> >> smell.
> >>
> >> * In particular, `elementWhere` is not a good label for the same
> >> reason that `removeElement` is not a good name. Session 403 last week
> >> actually talked about this between roughly minutes 8 and 11. (I'm sure
> >> you know about its content; you probably saw it before we did.)
> >
> > Yes I do, and I think you misinterpreted the message in that session.
> > There's nothing wrong with repeating type information when it's
> > necessary for clarity or fluency at the use-site.  In the case of
> > `contains(elementWhere:)`, it's there for fluency:
> >
> >customers.contains(where: isSingle)
> >
> > doesn't read as well as:
> >
> >customers.contains(elementWhere: isSingle)
> >
> > The point is not to imagine that every argument should be preceded by
> > a noun, and repetition of type information is often the result of
> > trying to do that.
> >
> >> * I like `separatedWhere` on `split`, but I think the Equatable
> >> version needs a similar renaming.
> >
> > That's a nice thought; I think it's arguably out-of-scope here, though.
> >
> >> Perhaps `separatedBy`?  `separatedOn`? The usual opposite of `where`,

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

2016-06-22 Thread Matthew Johnson via swift-evolution


>   * What is your evaluation of the proposal?

+11.  This is a much better default.  Escaping closures impose additional 
complexity on callers which should only be introduced when necessary.  

I am extremely unconvinced by the primary opposing argument that it should not 
be a breaking change to escape a closure that was not previously escaping.  
This is a significant semantic change.  If an API author wants to reserve the 
right to escape a closure they should explicitly opt-in to that semantic from 
the start.

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

Yes.  Unfortunately many programmers are not careful about providing 
annotations that are not strictly required by the compiler.  This means that 
the compiler currently must treat many closures as escaping even though they 
will never actually escape.  This change makes the language safer and easier to 
use.

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

Very much so.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No.

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

I followed and participated in the discussion and gave the final proposal a 
quick read.  I have always thought this is the right default for the language 
and am glad to see that this proposal is receiving positive feedback.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-22 Thread Dave Abrahams via swift-evolution


on Tue Jun 21 2016, Dave Abrahams  wrote:

> on Mon Jun 20 2016, Brent Royal-Gordon  wrote:
>
>>> A couple of weeks ago we started to notice that we had some poorly-named
>>> closure parameters and argument labels in the standard library, so we
>>> did a complete audit of the standard library's APIs and came up with a
>>> preliminary proposal for changes, which we applied in a branch and you
>>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>>> carry on further discussion here rather than in the pull request, though.
>>
>> In general, I like this; `orderingBy` is a particularly nice
>> improvement over the old `isOrderedBefore` convention. 
>
> I don't really love the use of “by”, FWIW, but I thought `orderingWith`
> was more confusable (ordering A with B might swap A and B, whereas the
> parameter is a closure).  It could be argued, though, that I am being
> overly concerned with unlikely misinterpretations, at the cost of
> “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open to
> discussion on this.
>
>> A few specific comments about things I don't like:
>>
>> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
>>   over `elementTransform`.
>
> I think you mean the converse.  And I agree that `elementTransform`
> is probably not an improvement over `transform`.

...and I've gone back to `transform` in my PR.

>> * In general, I'm not a fan of most of the changes away from `where`
>> labels. 
>
> The only such changes I can find are in
> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
>
> Note that part of this change was to make all filter closures
> consistent; in the main `filter` API there was no label at all.
> However, we felt that there's a real clarity problem with the polarity
> of the argument (we talk about “filtering things out” but the closure
> indicates which elements to keep).  And we couldn't find a “where”-based
> name that began to clarify it.
>
> I will argue that even changing to “suchThat,” as in the PR, does not
> sufficiently clarify the closure's polarity, and the only true fix for
> filter is to use a different base name (some have suggested “select,”
> and I have other ideas), but that is out of scope for this particular
> set of changes.  So if the community is happier with a “where” label
> here I can live with it.  I do think “suchThat” is marginally clearer.

I have not received any further pushback on “suchThat,” so I've left it
alone.

>
>> Those are a nice, straightforward convention applied broadly across
>> the Sequence APIs. (Yes, I criticized `where` as a method name in
>> another thread, but I don't think `where` is a problem when there's a
>> function base name to give it context.) When they don't work, that's
>> usually because of a less-than-ideal base name. I'm not saying that
>> *all* base names that aren't compatible with `where` should be
>> changed, but rather that if `where` is not enough, that's an API
>> smell.
>>
>> * In particular, `elementWhere` is not a good label for the same
>> reason that `removeElement` is not a good name. Session 403 last week
>> actually talked about this between roughly minutes 8 and 11. (I'm sure
>> you know about its content; you probably saw it before we did.)
>
> Yes I do, and I think you misinterpreted the message in that session.
> There's nothing wrong with repeating type information when it's
> necessary for clarity or fluency at the use-site.  In the case of
> `contains(elementWhere:)`, it's there for fluency:
>
>customers.contains(where: isSingle)
>
> doesn't read as well as:
>
>customers.contains(elementWhere: isSingle)
>
> The point is not to imagine that every argument should be preceded by
> a noun, and repetition of type information is often the result of
> trying to do that.
>
>> * I like `separatedWhere` on `split`, but I think the Equatable
>> version needs a similar renaming. 
>
> That's a nice thought; I think it's arguably out-of-scope here, though.
>
>> Perhaps `separatedBy`?  `separatedOn`? The usual opposite of `where`,
>> `of`, doesn't work here. (Alternatively, `separatedWhere` could be
>> `separatorWhere` instead, but that's not quite as elegant.)
>
> I'd want to consider variations of `separatingAt` or `onSeparator` or
> `atSeparator` too... which makes me thing “separatedWhere” might not be
> as good as “separatingWhere” for the closure version.
>
>> * I'm very uncomfortable with the amount of weight
>> `accumulatingResultBy` adds to `reduce`. `combinedBy` seems perfectly
>> cromulent to me. I'm even more concerned by your suggestion in the
>> pull request body of
>> `accumulating(startingFrom:combiningBy:)`. `reduce` is a subtle and
>> slightly confusing operation; adding more words to its call sites will
>> not solve that problem. If you want to invent a new name from whole
>> cloth, I would probably use something like

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread Matthew Johnson via swift-evolution

> On Jun 22, 2016, at 6:12 PM, John McCall  wrote:
> 
>> On Jun 22, 2016, at 2:42 PM, Matthew Johnson > > wrote:
>>> On Jun 22, 2016, at 4:29 PM, Javier Soto >> > wrote:
>>> 
>>> I'll work on a formal proposal for sealed by default :)
>> 
>> I have already been planning a proposal for sealed (in general) but didn’t 
>> think it fit with the goals of Swift 3 anymore (I had forgotten about the 
>> plan to make sealed the default).  
>> 
>> John, the modifier you allude to would be to allow inheritance outside the 
>> module, correct?  Would it also be appropriate to introduce `sealed`-like 
>> behavior for protocols (no protocol inheritance and / or conformance outside 
>> the module) along side sealed by default or should that still wait as it is 
>> purely additive?
> 
> That's additive.  'sealed' would be additive if it weren't primarily a 
> proposal to change the default rule, but we clearly aren't going to default 
> protocols that way.

That’s what I thought, just making sure. :)

> 
>> The proposal(s) I am planning is intended to achieve exhaustive pattern 
>> matching for classes and protocols.
> 
> Subclass matching can never be exhaustive in Swift as it stands because the 
> object can be an instance of the superclass.  You need to formalize abstract 
> classes before you can define that case away.

Actually my plan is to propose an “exact match” cast operator that allows for 
exhaustive pattern matching.  If we do get abstract classes that would allow an 
additional way for the compiler to prove exhaustiveness.

> 
> That aside, I agree that this proposal should provide sufficient information 
> for class/protocol exhaustiveness.  However, actually adding the language 
> rule for that should be a separate proposal and is very unlikely to land in 
> Swift 3.

That’s what I figured.  I’ll continue to sit on my ideas until we get past 
Swift 3.  

I would like to continue discussing what sealed protocols might look like so we 
can make sure this proposal aligns well with what we might want to do there.  
The tricky part is how we distinguish a sealing conformances from sealing 
refinements (if we need to be able to do that).  For example, are there cases 
where we would want to prevent protocols from inheriting a protocol while still 
allowing new conformances?  And conversely, are there cases where we would want 
to allow new protocols to refine the protocol and existing conformances to be 
“upgraded” to the new refined protocol?  If we want to support those use cases 
how might we make the necessary distinction syntactically?

It seems like the right thing to do for classes is pretty obvious (aside from 
the exact name for the “unsealed” modifier).  But I will feel more confident 
that we are doing the right thing if we also have a reasonably good idea of 
what we might do for protocols as well.

-Matthew

> 
> John.
> 
>> 
>>> 
>>> On Wed, Jun 22, 2016 at 1:43 PM John McCall >> > wrote:
 On Jun 22, 2016, at 1:38 PM, Matthew Johnson > wrote:
> On Jun 22, 2016, at 11:48 AM, John McCall  > wrote:
> 
>> On Jun 22, 2016, at 9:15 AM, Javier Soto > > wrote:
>> How would we evaluate the proposal to introduce the "sealed" specifier 
>> for classes (open within module, final outside of module) and default to 
>> that, in terms of source-code compatibility? 
>> From my point of view it might be easier to do before Swift 3, but if 
>> delayed until Swift 4 it wouldn't be the most time-consuming breakage 
>> for developers. 
> 
> I believe we consider this plan of record, actually, other than the 
> spelling of the modifier.  It's something we probably ought to commit to 
> in Swift 3, though.

 By “commit to in Swift 3” do you mean that it is likely the core team 
 would introduce a proposal for this in Swift 3?
>>> 
>>> We might be able to put the decision off as part of the larger resilience 
>>> feature, but I think it would be better to settle this in 3 if we can.  
>>> Who, exactly, authors the proposal is not settled; a community proposal 
>>> would be welcome.
>>> 
>>> John.
>>> 

> 
> John.
> 
>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Jun 22, 2016, at 10:59 AM, John McCall >> > wrote:
>>> 
>>> 
 On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution 
 > wrote:

> Rationalizing base

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

> We sometimes review proposals from framework teams like Apple and LibDispatch

Sorry, that should have been "Foundation and LibDispatch".

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

2016-06-22 Thread Brent Royal-Gordon via swift-evolution

> PROPOSING: Update WatchKit API Design to use properties instead of methods to 
> set properties

swift-evolution does not control how specific Apple frameworks, like WatchKit, 
get exposed to Swift. We sometimes review proposals from framework teams like 
Apple and LibDispatch on how they want to expose their APIs, but the details 
are still up to them. If you want to influence the design of Apple frameworks, 
the best way to do that is still Radar .

As for your specific proposal, the main problem I see with this is that these 
WatchKit classes offer only setters, not getters, and Swift doesn't support 
setter-only properties. Adding that support would not be very compatible with 
value types, because we need to be able to access the existing value in order 
to mutate it. I have nothing to do with the development of WatchKit, so I'm 
speculating, but I believe this design was chosen so that user interface 
updates could be asynchronous. Currently, nothing I can think of in WatchKit 
ever uses a return value; supporting getters in these APIs would run counter to 
that goal.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread Matthew Johnson via swift-evolution



Sent from my iPad

> On Jun 22, 2016, at 5:01 PM, Javier Soto  wrote:
> 
> Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the 
> proposal already: https://github.com/apple/swift-
> evolution/pull/376
> I would be happy to work with you on improving the proposal. I think your 
> mention to sealed protocols is super interesting, but I think that could be 
> additive. It might be easier to discuss each of them separately.

No problem!  The "by default" aspect is the most important part of your 
proposal and isn't something I was planning.  

I mentioned the proposal(s) I have in mind for a couple reasons.  Of course I 
wouldn't mind slipping something extra in if the core team thinks it makes 
sense.  

But more importantly, I mentioned this so future aspects of 'sealed' can be 
considered in the design.  Specifically, in the case of protocols there are two 
avenues for sealing them - refinements by other protocols and conformances by 
types.  I haven't figured out the best way to make that distinction yet (if you 
have any ideas please chime in).  Ideally the path forward would be clear 
before your proposal is reviewed even if the addition for protocols happens 
after Swift 3.

-Matthew

> 
> On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson  
> wrote:
>>> On Jun 22, 2016, at 4:29 PM, Javier Soto  wrote:
>>> 
>>> I'll work on a formal proposal for sealed by default :)
>> 
>> I have already been planning a proposal for sealed (in general) but didn’t 
>> think it fit with the goals of Swift 3 anymore (I had forgotten about the 
>> plan to make sealed the default).  
>> 
>> John, the modifier you allude to would be to allow inheritance outside the 
>> module, correct?  Would it also be appropriate to introduce `sealed`-like 
>> behavior for protocols (no protocol inheritance and / or conformance outside 
>> the module) along side sealed by default or should that still wait as it is 
>> purely additive?
>> 
>> The proposal(s) I am planning is intended to achieve exhaustive pattern 
>> matching for classes and protocols.
>> 
>>> 
>>> On Wed, Jun 22, 2016 at 1:43 PM John McCall  wrote:
>> On Jun 22, 2016, at 1:38 PM, Matthew Johnson  
>> wrote:
>>> On Jun 22, 2016, at 11:48 AM, John McCall  wrote:
>>> 
>>> On Jun 22, 2016, at 9:15 AM, Javier Soto  wrote:
>>> How would we evaluate the proposal to introduce the "sealed" specifier 
>>> for classes (open within module, final outside of module) and default 
>>> to that, in terms of source-code compatibility? 
>>> From my point of view it might be easier to do before Swift 3, but if 
>>> delayed until Swift 4 it wouldn't be the most time-consuming breakage 
>>> for developers. 
>> 
>> I believe we consider this plan of record, actually, other than the 
>> spelling of the modifier.  It's something we probably ought to commit to 
>> in Swift 3, though.
> 
> By “commit to in Swift 3” do you mean that it is likely the core team 
> would introduce a proposal for this in Swift 3?
 
 We might be able to put the decision off as part of the larger resilience 
 feature, but I think it would be better to settle this in 3 if we can.  
 Who, exactly, authors the proposal is not settled; a community proposal 
 would be welcome.
 
 John.
 
> 
>> 
>> John.
>> 
>>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution 
>>>  wrote:
>> On Jun 22, 2016, at 10:59 AM, John McCall  wrote:
>> 
>> 
>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> Rationalizing base conversion protocol names. I personally don't 
>>> have the heart to try to re-address the "LiteralConvertible" 
>>> protocol naming thing again but this would be the last chance to do 
>>> anything about getting this issue addressed.
>> Given the vast amount of bike shedding that has already happened 
>> around this topic, I don’t think there is a solution that everyone 
>> will be happy with.  It is also unclear (to me at least) what 
>> solution might be acceptable to the core team.  
> 
> To be clear, I don't care about the name.  If you want to rename 
> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag 
> the conversation into the muck again. :)  It's the design of the 
> requirements that I'm pretty opposed to revisiting.
 
 This is orthogonal to the discussion that happened in your thread, 
 definitely no discussion of any changes to the requirements. :)
 
 We are discussing this

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread John McCall via swift-evolution

> On Jun 22, 2016, at 2:42 PM, Matthew Johnson  wrote:
>> On Jun 22, 2016, at 4:29 PM, Javier Soto > > wrote:
>> 
>> I'll work on a formal proposal for sealed by default :)
> 
> I have already been planning a proposal for sealed (in general) but didn’t 
> think it fit with the goals of Swift 3 anymore (I had forgotten about the 
> plan to make sealed the default).  
> 
> John, the modifier you allude to would be to allow inheritance outside the 
> module, correct?  Would it also be appropriate to introduce `sealed`-like 
> behavior for protocols (no protocol inheritance and / or conformance outside 
> the module) along side sealed by default or should that still wait as it is 
> purely additive?

That's additive.  'sealed' would be additive if it weren't primarily a proposal 
to change the default rule, but we clearly aren't going to default protocols 
that way.

> The proposal(s) I am planning is intended to achieve exhaustive pattern 
> matching for classes and protocols.

Subclass matching can never be exhaustive in Swift as it stands because the 
object can be an instance of the superclass.  You need to formalize abstract 
classes before you can define that case away.

That aside, I agree that this proposal should provide sufficient information 
for class/protocol exhaustiveness.  However, actually adding the language rule 
for that should be a separate proposal and is very unlikely to land in Swift 3.

John.

> 
>> 
>> On Wed, Jun 22, 2016 at 1:43 PM John McCall > > wrote:
>>> On Jun 22, 2016, at 1:38 PM, Matthew Johnson >> > wrote:
 On Jun 22, 2016, at 11:48 AM, John McCall > wrote:
 
> On Jun 22, 2016, at 9:15 AM, Javier Soto  > wrote:
> How would we evaluate the proposal to introduce the "sealed" specifier 
> for classes (open within module, final outside of module) and default to 
> that, in terms of source-code compatibility? 
> From my point of view it might be easier to do before Swift 3, but if 
> delayed until Swift 4 it wouldn't be the most time-consuming breakage for 
> developers. 
 
 I believe we consider this plan of record, actually, other than the 
 spelling of the modifier.  It's something we probably ought to commit to 
 in Swift 3, though.
>>> 
>>> By “commit to in Swift 3” do you mean that it is likely the core team would 
>>> introduce a proposal for this in Swift 3?
>> 
>> We might be able to put the decision off as part of the larger resilience 
>> feature, but I think it would be better to settle this in 3 if we can.  Who, 
>> exactly, authors the proposal is not settled; a community proposal would be 
>> welcome.
>> 
>> John.
>> 
>>> 
 
 John.
 
> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution 
> > wrote:
>> On Jun 22, 2016, at 10:59 AM, John McCall > > wrote:
>> 
>> 
>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 Rationalizing base conversion protocol names. I personally don't have 
 the heart to try to re-address the "LiteralConvertible" protocol 
 naming thing again but this would be the last chance to do anything 
 about getting this issue addressed.
>>> Given the vast amount of bike shedding that has already happened around 
>>> this topic, I don’t think there is a solution that everyone will be 
>>> happy with.  It is also unclear (to me at least) what solution might be 
>>> acceptable to the core team.  
>> 
>> To be clear, I don't care about the name.  If you want to rename 
>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag 
>> the conversation into the muck again. :)  It's the design of the 
>> requirements that I'm pretty opposed to revisiting.
> 
> This is orthogonal to the discussion that happened in your thread, 
> definitely no discussion of any changes to the requirements. :)
> 
> We are discussing this proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>  
> 
>  and specifically the use of the `Convertible` suffix for both the 
> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible` 
> protocols where the conversion runs in opposite directions.
> 
> The core team decision was:
> 
> "The feedback on the proposal

Re: [swift-evolution] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

2016-06-22 Thread Tony Allevato via swift-evolution

Doing this would require a larger change in Swift than a single API.
WKInterfaceLabel is "one-way" in the sense that those values can be set
with setter methods, but there is no API to get the values back. This can't
map to properties in Swift as they're implemented today, because a property
with a custom setter must also have a custom getter.

That being said, a property is intended to be something that *can* be read
and used elsewhere in expressions, like a variable, so such a change
wouldn't (in my opinion) be warranted. The fact that the setting is through
an explicit set* method instead of a property makes it stand out to the
user as something that doesn't function like a regular property does.


On Wed, Jun 22, 2016 at 4:03 PM Michie via swift-evolution <
swift-evolution@swift.org> wrote:

> *PROPOSING: Update WatchKit API Design to use properties instead of
> methods to set properties*
>
> by Michie - https://github.com/michieriffic
>
>
> *Introduction*
>
> WKInterfaceLabel is still using methods for set Text (setText), set Text
> Color (setTextColor), set Attributed Text (setAttributedText) to set
> properties of WKInterfaceLabel. I think it's more appropriate to make these
> into properties rather than methods just like in the UILabel. That would
> make it more consistent with building apps for both iOS, MacOS, WatchOS,
> and more.
>
> Also, other objects in WatchKit needs to be updated too to use properties
> instead of methods to set properties so we can easily access it using dot
> notation. WKInterfaceLabel is just an example.
>
> *Motivation*
>
> While creating an app for watchOS, it has been a habit for me to use the
> dot notation to access a property of an object and set it using "=". And
> text, textColor, and attributedText are properties rather than methods of
> an object.
>
> *Proposed solution & detailed design*
>
> public class WKInterfaceLabel : WKInterfaceObject {
>
>public var text: String?
>public var textColor: UIColor?
>@NSCopying public var attributedText: AttributedString?
>
> }
>
> *INSTEAD OF*
>
> public class WKInterfaceLabel : WKInterfaceObject {
>
>public func setText(_ text: String?)
>public func setTextColor(_ color: UIColor?)
>public func setAttributedText(_ attributtedText: AttributedString?)
>
> }
>
> *Impact on existing code*
>
> Impact: *Would be more consistent and natural to the Swift language when
> building apps for WatchOS*
>
> *Before:*
>
>   watchLabel.setText("Text String")
>   watchLabel.setTextColor(UIColor.red())
>
> *After:*
>
>   watchLabel.text = "Text String"
>   watchLabel.textColor = UIColor.red()
>
> Will some Swift applications stop compiling due to this change? *Possible*
>
> Will applications still compile but produce different behavior than they
> used to? *No, if everything was migrated properly.*
>
> Is it possible to migrate existing Swift code to use a new feature or API
> automatically? *Yes.*
>
> *Alternatives considered*
>
> Just use what's currently available.
> ___
> 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] [PITCH] WatchKit API Design Change to use properties instead of methods to set properties

2016-06-22 Thread Michie via swift-evolution


 PROPOSING: UPDATE WATCHKIT API DESIGN TO USE PROPERTIES INSTEAD OF METHODS
TO SET PROPERTIES

 by Michie - https://github.com/michieriffic


INTRODUCTION

WKInterfaceLabel is still using methods for set Text (setText), set Text
Color (setTextColor), set Attributed Text (setAttributedText) to set
properties of WKInterfaceLabel. I think it's more appropriate to make these
into properties rather than methods just like in the UILabel. That would
make it more consistent with building apps for both iOS, MacOS, WatchOS,
and more.

Also, other objects in WatchKit needs to be updated too to use properties
instead of methods to set properties so we can easily access it using dot
notation. WKInterfaceLabel is just an example.

MOTIVATION

While creating an app for watchOS, it has been a habit for me to use the
dot notation to access a property of an object and set it using "=". And
text, textColor, and attributedText are properties rather than methods of
an object.

PROPOSED SOLUTION & DETAILED DESIGN

public class WKInterfaceLabel : WKInterfaceObject {

   public var text: String?
   public var textColor: UIColor?
   @NSCopying public var attributedText: AttributedString?

}

/INSTEAD OF/

public class WKInterfaceLabel : WKInterfaceObject {

   public func setText(_ text: String?)
   public func setTextColor(_ color: UIColor?)
   public func setAttributedText(_ attributtedText: AttributedString?)

}

IMPACT ON EXISTING CODE

Impact: /Would be more consistent and natural to the Swift language when
building apps for WatchOS/

BEFORE:

  watchLabel.setText("Text String")
  watchLabel.setTextColor(UIColor.red())

 AFTER:

  watchLabel.text = "Text String"
  watchLabel.textColor = UIColor.red()

 Will some Swift applications stop compiling due to this change? /Possible/

Will applications still compile but produce different behavior than they
used to? /No, if everything was migrated properly./

Is it possible to migrate existing Swift code to use a new feature or API
automatically? /Yes./

ALTERNATIVES CONSIDERED

Just use what's currently available.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Andrew Bennett via swift-evolution

I agree that there should be a type for a non-destructive re-entrant
sequence.

IIRC in past discussions one of the counter arguments given was IO stream
sequences. It is likely undesirable to buffer the entire stream, but
without buffering there's no guarantee of getting the same values.

These discussions were back when swift-evolution started, sorry I couldn't
find a link. I think it was discussed in the context of a non-mutating
Generator.

On Thursday, 23 June 2016, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >
> > on Wed Jun 22 2016, David Waite  > wrote:
> >
> >> Today, a Sequence differs from a Collection in that:
> >>
> >> - A sequence can be infinitely or indefinitely sized, or could require
> >> an O(n) operation to count the values in the sequence.
> >
> > The latter being no different from Collection.
> >
> >> A collection has a finite number of elements, and the fixed size is
> >> exposed as an O(1) or O(n) operation via ‘count’
> >
> > I don't believe we've actually nailed down that Collection is finite.
> >
> > Oh, gee, Nate's documentation edits do
> > that. (https://github.com/apple/swift/commit/6e274913)
> > Nate, did we discuss this explicitly or did it slip in unnoticed?
> >
> > The one crucial distinction in Collection is that you can make multiple
> > passes over the same elements.
> >
> >> - A collection is indexable, with those indices being usable for
> >> various operations including forming subsets, comparisons, and manual
> >> iteration
> >>
> >> - A sequence may or may not be destructive, where a destructive
> >> sequence consumes elements during traversal, making them unavailable
> >> on subsequent traversals. Collection operations are required to be
> >> non-destructive
> >>
> >> I would like to Pitch removing this third differentiation, the option
> >> for destructive sequences.
> >
> > I have been strongly considering this direction myself, and it's
> > something we need to decide about for Swift 3.
>
> I believe this is a problem that should be solved.
>
> I also believe distinguishing between finite and infinite sequences is a
> good idea (along with preventing for..in from being used with an infinite
> sequence)
>
> >
> >> My main motivation for proposing this is the potential for developer
> >> confusion. As stated during one of the previous threads on the naming
> >> of map, flatMap, filter, etc. methods on Sequence, Sequence has a
> >> naming requirement not typical of the rest of the Swift standard
> >> library in that many methods on Sequence may or may not be
> >> destructive. As such, naming methods for any extensions on Sequence is
> >> challenging as the names need to not imply immutability.
> >
> > I don't think the names are really the worst potential cause of
> > confusion here.  There's also the fact that you can conform to Sequence
> > with a destructively-traversed “value type” that has no mutating
> > methods.
>
> I agree, names are not the primary issue.
>
> Another issue is that you cannot currently write generic code that might
> need to iterate a sequence more than once.  You currently have to
> over-constrain types to `Collection` even if you don’t need to do anything
> other than iterate the elements (the discussion about whether
> `LazyFilterSequnce` has a bug in its `underestimateCount` is relevant here).
>
> >
> >> It would still be possible to have Generators which operate
> >
> >  “Iterators,” please.
> >
> >> destructively, but such Generators would not conform to the needs of
> >> Sequence. As such, the most significant impact would be the inability
> >> to use such Generators in a for..in loop,
> >
> > Trying to evaluate this statement, it's clear we're missing lots of
> > detail here:
> >
> > * Would you remove Sequence?
> > * If so, what Protocol would embody “for...in-able?”
> > * If not, would you remove Collection?
> > * What role would Iterator play?
>
> If we’re going to consider alternative designs it is worth considering the
> semantic space available.  For the sake of discussion, here is a model that
> captures the various semantics that exist (the names are just strawmen):
>
>Iterable
>/  \
>   / \
>  /   \
> FiniteIterable MultipassIterable
> \ /
>   \  /
>\/
>   Sequence
>  |
>  |
>   Collection
>
> `Iterable` corresponds to the current `Sequence` - no semantics beyond
> iteration are required.  Infinite, single-pass “sequences” may conform.
>
> `for..in`

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Matthew Johnson via swift-evolution

> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 22 2016, David Waite  wrote:
> 
>> Today, a Sequence differs from a Collection in that:
>> 
>> - A sequence can be infinitely or indefinitely sized, or could require
>> an O(n) operation to count the values in the sequence. 
> 
> The latter being no different from Collection.
> 
>> A collection has a finite number of elements, and the fixed size is
>> exposed as an O(1) or O(n) operation via ‘count’
> 
> I don't believe we've actually nailed down that Collection is finite.
> 
> Oh, gee, Nate's documentation edits do
> that. (https://github.com/apple/swift/commit/6e274913)
> Nate, did we discuss this explicitly or did it slip in unnoticed?
> 
> The one crucial distinction in Collection is that you can make multiple
> passes over the same elements.
> 
>> - A collection is indexable, with those indices being usable for
>> various operations including forming subsets, comparisons, and manual
>> iteration
>> 
>> - A sequence may or may not be destructive, where a destructive
>> sequence consumes elements during traversal, making them unavailable
>> on subsequent traversals. Collection operations are required to be
>> non-destructive
>> 
>> I would like to Pitch removing this third differentiation, the option
>> for destructive sequences.
> 
> I have been strongly considering this direction myself, and it's
> something we need to decide about for Swift 3.

I believe this is a problem that should be solved.  

I also believe distinguishing between finite and infinite sequences is a good 
idea (along with preventing for..in from being used with an infinite sequence)

> 
>> My main motivation for proposing this is the potential for developer
>> confusion. As stated during one of the previous threads on the naming
>> of map, flatMap, filter, etc. methods on Sequence, Sequence has a
>> naming requirement not typical of the rest of the Swift standard
>> library in that many methods on Sequence may or may not be
>> destructive. As such, naming methods for any extensions on Sequence is
>> challenging as the names need to not imply immutability.
> 
> I don't think the names are really the worst potential cause of
> confusion here.  There's also the fact that you can conform to Sequence
> with a destructively-traversed “value type” that has no mutating
> methods.

I agree, names are not the primary issue.  

Another issue is that you cannot currently write generic code that might need 
to iterate a sequence more than once.  You currently have to over-constrain 
types to `Collection` even if you don’t need to do anything other than iterate 
the elements (the discussion about whether `LazyFilterSequnce` has a bug in its 
`underestimateCount` is relevant here).

> 
>> It would still be possible to have Generators which operate
> 
>  “Iterators,” please.
> 
>> destructively, but such Generators would not conform to the needs of
>> Sequence. As such, the most significant impact would be the inability
>> to use such Generators in a for..in loop, 
> 
> Trying to evaluate this statement, it's clear we're missing lots of
> detail here:
> 
> * Would you remove Sequence?
> * If so, what Protocol would embody “for...in-able?”
> * If not, would you remove Collection?
> * What role would Iterator play?

If we’re going to consider alternative designs it is worth considering the 
semantic space available.  For the sake of discussion, here is a model that 
captures the various semantics that exist (the names are just strawmen):

   Iterable 
   /  \
  / \
 /   \
FiniteIterable MultipassIterable
\ /
  \  / 
   \/
  Sequence
 |
 |
  Collection

`Iterable` corresponds to the current `Sequence` - no semantics beyond 
iteration are required.  Infinite, single-pass “sequences” may conform.  

`for..in` naturally requires `FiniteIterable`, but does not require the 
`MultipassIterable`.

There are many interesting infinite `MultipassIterable` types.  These include 
any dynamically generated sequence, such as a mathematical sequence (even 
numbers, odd numbers, etc).  This is also what the existing `Sequence` would 
become if we drop support for destructive sequences and do nothing else (note: 
it would still be possible to accidentally write a `for..in` loop over an 
infinite sequence).

Under this model `Sequence` brings together `FiniteIterable` and 
`MultipassIterable`.  This describes the most common models of `Sequence`, can 
safely be used in a `for..in` loop, and does support “destructive” single pass 
sequences.

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread Javier Soto via swift-evolution

Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the
proposal already: https://github.com/apple/swift-
evolution/pull/376
I would be happy to work with you on improving the proposal. I think your
mention to sealed protocols is super interesting, but I think that could be
additive. It might be easier to discuss each of them separately.

On Wed, Jun 22, 2016 at 2:42 PM Matthew Johnson 
wrote:

> On Jun 22, 2016, at 4:29 PM, Javier Soto  wrote:
>
> I'll work on a formal proposal for sealed by default :)
>
>
> I have already been planning a proposal for sealed (in general) but didn’t
> think it fit with the goals of Swift 3 anymore (I had forgotten about the
> plan to make sealed the default).
>
> John, the modifier you allude to would be to allow inheritance outside the
> module, correct?  Would it also be appropriate to introduce `sealed`-like
> behavior for protocols (no protocol inheritance and / or conformance
> outside the module) along side sealed by default or should that still wait
> as it is purely additive?
>
> The proposal(s) I am planning is intended to achieve exhaustive pattern
> matching for classes and protocols.
>
>
> On Wed, Jun 22, 2016 at 1:43 PM John McCall  wrote:
>
>> On Jun 22, 2016, at 1:38 PM, Matthew Johnson 
>> wrote:
>>
>> On Jun 22, 2016, at 11:48 AM, John McCall  wrote:
>>
>> On Jun 22, 2016, at 9:15 AM, Javier Soto  wrote:
>> How would we evaluate the proposal to introduce the "sealed" specifier
>> for classes (open within module, final outside of module) and default to
>> that, in terms of source-code compatibility?
>> From my point of view it might be easier to do before Swift 3, but if
>> delayed until Swift 4 it wouldn't be the most time-consuming breakage for
>> developers.
>>
>>
>> I believe we consider this plan of record, actually, other than the
>> spelling of the modifier.  It's something we probably ought to commit to in
>> Swift 3, though.
>>
>>
>> By “commit to in Swift 3” do you mean that it is likely the core team
>> would introduce a proposal for this in Swift 3?
>>
>>
>> We might be able to put the decision off as part of the larger resilience
>> feature, but I think it would be better to settle this in 3 if we can.
>> Who, exactly, authors the proposal is not settled; a community proposal
>> would be welcome.
>>
>> John.
>>
>>
>>
>> John.
>>
>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Jun 22, 2016, at 10:59 AM, John McCall  wrote:
>>>
>>>
>>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>>- Rationalizing base conversion protocol names. I personally don't
>>>have the heart to try to re-address the "LiteralConvertible" protocol
>>>naming thing again but this would be the last chance to do anything about
>>>getting this issue addressed.
>>>
>>> Given the vast amount of bike shedding that has already happened around
>>> this topic, I don’t think there is a solution that everyone will be happy
>>> with.  It is also unclear (to me at least) what solution might be
>>> acceptable to the core team.
>>>
>>>
>>> To be clear, I don't care about the name.  If you want to rename
>>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the
>>> conversation into the muck again. :)  It's the design of the requirements
>>> that I'm pretty opposed to revisiting.
>>>
>>>
>>> This is orthogonal to the discussion that happened in your thread,
>>> definitely no discussion of any changes to the requirements. :)
>>>
>>> We are discussing this proposal:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>  and
>>> specifically the use of the `Convertible` suffix for both the
>>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible`
>>> protocols where the conversion runs in opposite directions.
>>>
>>> The core team decision was:
>>>
>>> "The feedback on the proposal was generally positive about the idea of
>>> renaming these protocols, but the specific names in the proposal are not
>>> well received, and there is no apparent confluence in the community on
>>> better names.  The core team prefers discussion to continue -- if/when
>>> there is a strong proposal for a better naming approach, we can reconsider
>>> renaming these."
>>>
>>>
>>> John.
>>>
>>>
>>> At the same time, it continues to bother me that `Convertible` is used
>>> by standard library protocols with two completely different meanings.  This
>>> is a problem that deserves to be solved and as it involves a breaking
>>> change Swift 3 is the right timeframe in which to do so.
>>>
>>> If the core team is able to indicate an approach they favor I would be
>>> willing to revise and resubmit the proposal.

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

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> As you will see from earlier messages, the confused user is both quite real 
> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
> trivialized; they are serious concerns for the design of the language. On 
> what grounds do you assert that something is "not confusing at all" when 
> there has been testimony saying "it was confusing to me"?
> 
> Some of us on this list interact regularly with novice coders. I draw upon 
> these experiences here. Do you have some special insight you'd like to share 
> in that regard?
> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  > wrote:
> How about the goal of it being a delightful language to program in. I think 
> that is getting lost in proposals like these. Optimizing for some mythical 
> new user, who really isn’t present on this list to give an opinion seems like 
> a false argument to make, and your technical sophistication makes you a less 
> qualified than most to say what is and what isn’t confusing to new users 
> because you haven’t been one in a long time.
> 
> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.
> 
> Cheers

Yet another case from a few minutes ago:

[3:08pm] rullie: hi, could someone walk me through this 
http://pastie.org/10887040
[3:08pm] rullie: why is it that for loop through an lazy infinite sequence does 
not terminate even with the where clause invovled?
[3:08pm] mikeash: "where" means "skip iterations when this condition is not 
true"
[3:08pm] mikeash: it doesn't mean "halt the loop when this is not true"
[3:08pm] rullie: oh whoa.. ok
[3:09pm] mikeash: it can't know that you'll never see another value < 100, so 
it keeps on going
[3:09pm] rullie: ok, i completely misunderstood the where clause then
[3:10pm] mikeash: I can see how it might look like it does that
[3:10pm] rullie: is there a syntax that achieves what i want to do without 
having to have a if-break in the loop?

-- E
p.s. Posted with permission from both participants

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

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

2016-06-22 Thread William Shipley via swift-evolution

I agree with this proposal. In my own code I’ve found non-escaping parameters 
to be far and away the most common I create, with only the very occasional 
block that could escape.

Most times when I’ve seen escaping blocks in the wild it’s in Apple’s 
frameworks — which makes sense, because Apple’s written GCD and there’s no 
point in all of us duplicating it.

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

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread Javier Soto via swift-evolution

I'll work on a formal proposal for sealed by default :)

On Wed, Jun 22, 2016 at 1:43 PM John McCall  wrote:

> On Jun 22, 2016, at 1:38 PM, Matthew Johnson 
> wrote:
>
> On Jun 22, 2016, at 11:48 AM, John McCall  wrote:
>
> On Jun 22, 2016, at 9:15 AM, Javier Soto  wrote:
> How would we evaluate the proposal to introduce the "sealed" specifier for
> classes (open within module, final outside of module) and default to that,
> in terms of source-code compatibility?
> From my point of view it might be easier to do before Swift 3, but if
> delayed until Swift 4 it wouldn't be the most time-consuming breakage for
> developers.
>
>
> I believe we consider this plan of record, actually, other than the
> spelling of the modifier.  It's something we probably ought to commit to in
> Swift 3, though.
>
>
> By “commit to in Swift 3” do you mean that it is likely the core team
> would introduce a proposal for this in Swift 3?
>
>
> We might be able to put the decision off as part of the larger resilience
> feature, but I think it would be better to settle this in 3 if we can.
> Who, exactly, authors the proposal is not settled; a community proposal
> would be welcome.
>
> John.
>
>
>
> John.
>
> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 22, 2016, at 10:59 AM, John McCall  wrote:
>>
>>
>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>- Rationalizing base conversion protocol names. I personally don't
>>have the heart to try to re-address the "LiteralConvertible" protocol
>>naming thing again but this would be the last chance to do anything about
>>getting this issue addressed.
>>
>> Given the vast amount of bike shedding that has already happened around
>> this topic, I don’t think there is a solution that everyone will be happy
>> with.  It is also unclear (to me at least) what solution might be
>> acceptable to the core team.
>>
>>
>> To be clear, I don't care about the name.  If you want to rename
>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the
>> conversation into the muck again. :)  It's the design of the requirements
>> that I'm pretty opposed to revisiting.
>>
>>
>> This is orthogonal to the discussion that happened in your thread,
>> definitely no discussion of any changes to the requirements. :)
>>
>> We are discussing this proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>  and
>> specifically the use of the `Convertible` suffix for both the
>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible`
>> protocols where the conversion runs in opposite directions.
>>
>> The core team decision was:
>>
>> "The feedback on the proposal was generally positive about the idea of
>> renaming these protocols, but the specific names in the proposal are not
>> well received, and there is no apparent confluence in the community on
>> better names.  The core team prefers discussion to continue -- if/when
>> there is a strong proposal for a better naming approach, we can reconsider
>> renaming these."
>>
>>
>> John.
>>
>>
>> At the same time, it continues to bother me that `Convertible` is used by
>> standard library protocols with two completely different meanings.  This is
>> a problem that deserves to be solved and as it involves a breaking change
>> Swift 3 is the right timeframe in which to do so.
>>
>> If the core team is able to indicate an approach they favor I would be
>> willing to revise and resubmit the proposal.  But I don’t want to spend any
>> further time speculating about what solution might be considered acceptable.
>>
>> Matthew
>>
>> ___
>> 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
>>
> --
> Javier Soto
>
>
>
>
> --
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-22 Thread Scott James Remnant via swift-evolution

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> As you will see from earlier messages, the confused user is both quite real 
> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
> trivialized; they are serious concerns for the design of the language. On 
> what grounds do you assert that something is "not confusing at all" when 
> there has been testimony saying "it was confusing to me"?
> 
> Some of us on this list interact regularly with novice coders. I draw upon 
> these experiences here. Do you have some special insight you'd like to share 
> in that regard?
> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  > wrote:
> How about the goal of it being a delightful language to program in. I think 
> that is getting lost in proposals like these. Optimizing for some mythical 
> new user, who really isn’t present on this list to give an opinion seems like 
> a false argument to make, and your technical sophistication makes you a less 
> qualified than most to say what is and what isn’t confusing to new users 
> because you haven’t been one in a long time.
> 
> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.
> 
> Cheers

Yet another case from a few minutes ago:

rullie : hi, could someone walk me through this 
http://pastie.org/10887040 
[3:08pm] rullie : why is it that for loop through an lazy 
infinite sequence does not terminate even with the where clause invovled?
[
[3:08pm] mikeash : "where" means "skip iterations when this 
condition is not true"
[3:08pm] mikeash : it doesn't mean "halt the loop when this is 
not true"
[3:08pm] rullie : oh whoa.. ok
[3:09pm] mikeash : it can't know that you'll never see another 
value < 100, so  it keeps on going
[3:09pm] rullie : ok, i completely misunderstood the where 
clause then
[3:10pm] mikeash : I can see how it might look like it does that
[3:10pm] rullie : is there a syntax that achieves what i want to 
do without having to have a if-break in the loop?

-- E
p.s. Posted with permission from both participants

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

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

2016-06-22 Thread Sean Heber via swift-evolution

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

>   * What is your evaluation of the proposal?

Huge +1. I think this will lead to safer, faster code by default and better 
errors and warnings.


>   * 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?

Yes.


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

n/a


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

Followed the discussion, read the proposal twice.

l8r
Sean

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

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

2016-06-22 Thread Gwynne Raskind via swift-evolution

>   * What is your evaluation of the proposal?

I’m strongly in favor - improvements on retain cycle issues are a huge win, and 
escaping as the default better fits the visual layout of the code and forces 
the developer to think more for the case that’s more conceptually complicated 
instead of the simple one. The way I read it also suggests that the compiler 
will be able to give better warnings with nonescaping as the default, and 
better warnings are rarely a bad thing :). I also like the normalization of the 
otherwise somewhat awkward and redundant @autoclosure(escaping) syntax - with 
nonescaping as the default, this is no longer a place where there’s a 
disconnect between closure behaviors in different contexts.

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

Definitely; retain cycles are bad enough without making them more painful than 
they need to be, matching the code’s behavior to its appearance is a net win 
for ease of use, and the removal of the @autoclosure(escaping) syntax cleans up 
a place where the language often looks as if it’s deliberately being pedantic 
in a context where the intent is obvious.

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

I couldn’t imagine a better fit - an improvement to syntax, intent, 
consistency, and behavior all at once; being able to make such improvements is 
one of the fundamental essences of Swift (at least as I understand it :).

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I haven’t used any languages which have a similar feature, unless you count 
Objective-C and its lack of a "nonescaping" syntax (or concept) for blocks (I 
imagine Clang has code to optimize them when it does detect them, but it 
definitely wasn't part of the blocks spec last time I read it.) Speaking from 
that experience and what I’ve done with closures in Swift, I definitely like 
being able to declare explicitly that my closure doesn’t escape; it clarifies 
my intent without needing extra text in my headerdocs explaining the block’s 
semantics. I like it even better with nonescaping as the default - consumers of 
my API (including myself) don’t have to think nearly as hard about retain 
cycles in a surprising number of cases (I obviously don’t do much Objective-C 
bridging ^^; )

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

I gave it a moderate amount of attention; I haven’t done deep research or 
refreshed my memory of the semantics further than a quick skim, but I don’t 
think there are many corner cases that need consideration for this proposal 
(which is another reason I like it and the way proposals in Swift are done in 
general). (Also, I generally trust my memory for semantics I was working with 
successfully an hour ago :)

-- Gwynne Raskind

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Dave Abrahams via swift-evolution

on Wed Jun 22 2016, David Waite  wrote:

> Today, a Sequence differs from a Collection in that:
>
> - A sequence can be infinitely or indefinitely sized, or could require
> an O(n) operation to count the values in the sequence. 

The latter being no different from Collection.

> A collection has a finite number of elements, and the fixed size is
> exposed as an O(1) or O(n) operation via ‘count’

I don't believe we've actually nailed down that Collection is finite.

Oh, gee, Nate's documentation edits do
that. (https://github.com/apple/swift/commit/6e274913)
Nate, did we discuss this explicitly or did it slip in unnoticed?

The one crucial distinction in Collection is that you can make multiple
passes over the same elements.

> - A collection is indexable, with those indices being usable for
> various operations including forming subsets, comparisons, and manual
> iteration
>
> - A sequence may or may not be destructive, where a destructive
> sequence consumes elements during traversal, making them unavailable
> on subsequent traversals. Collection operations are required to be
> non-destructive
>
> I would like to Pitch removing this third differentiation, the option
> for destructive sequences.

I have been strongly considering this direction myself, and it's
something we need to decide about for Swift 3.

> My main motivation for proposing this is the potential for developer
> confusion. As stated during one of the previous threads on the naming
> of map, flatMap, filter, etc. methods on Sequence, Sequence has a
> naming requirement not typical of the rest of the Swift standard
> library in that many methods on Sequence may or may not be
> destructive. As such, naming methods for any extensions on Sequence is
> challenging as the names need to not imply immutability.

I don't think the names are really the worst potential cause of
confusion here.  There's also the fact that you can conform to Sequence
with a destructively-traversed “value type” that has no mutating
methods.

> It would still be possible to have Generators which operate

 “Iterators,” please.

> destructively, but such Generators would not conform to the needs of
> Sequence. As such, the most significant impact would be the inability
> to use such Generators in a for..in loop, 

Trying to evaluate this statement, it's clear we're missing lots of
detail here:

* Would you remove Sequence?
* If so, what Protocol would embody “for...in-able?”
* If not, would you remove Collection?
* What role would Iterator play?

-- 
Dave

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

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

2016-06-22 Thread Sean Heber via swift-evolution

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

I think I like it and it seems straight-forward enough.


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

I cannot say if it is significant “enough” but I think it results in cleaner 
looking code that doesn’t end up reading as if generics are being used when 
they are not.


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

I believe so.


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

n/a


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

Minimal attention-paying during the discussions, 2 readings of the current 
proposal.

l8r
Sean

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

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 12:57 PM, David Sweeris  wrote:
>
>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>>
>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>>  wrote:
>>
>> Hi Erica,
>>
>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
>> and me from the last time this was discussed.  Unfortunately I can't
>> find the exact email, so I can't provide a link.
>>
>> - The "literal" protocols are not about conversion, they are about
>> adopting a certain syntax provided by the language.  "Convertible" in
>> the name is a red herring: a type can't be convertible from an integer
>> literal because there is no "IntegerLiteral" entity in the type
>> system.  The literal *becomes* typed as the corresponding literal type
>> (e.g., Int or String), and as far as the user at the call site is
>> concerned, there is no visible conversion (even if one is happening
>> behind the scenes).
>>
>> Our suggestion was to focus on the "adopting the syntax" part.  We
>> suggested moving the "literal convertible" protocols into a
>> pseudo-namespace "Syntax".  It could be implemented like this:
>>
>> protocol _IntegerLiteralSyntax {}
>> enum Syntax {
>>  typealias IntegerLiteral = _IntegerLiteralSyntax
>> }
>>
>> And used like this:
>>
>> struct Int : Syntax.IntegerLiteral {}
>>
>> - For protocols that are representing conversions between types that
>> actually exist in the library, there is not enough precedent yet to
>> make a general conclusion and standardize a pattern.
>
> I’m not sure I understand… In this example, has “IntegerLiteralConvertible” 
> been renamed to “_IntegerLiteralSyntax”?

That's right.  But we want users to refer to the protocol as
'Syntax.IntegerLiteral'.  If/once we get either submodules or
protocols nested in enums, we can move the actual definition to be
nested.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, David Sweeris  wrote:

>> On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> 
>> On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
>>  wrote:
>> 
>
>> Hi Erica,
>> 
>> I would like to re-state the feedback from Dave Abrahams, Max Moiseev
>> and me from the last time this was discussed.  Unfortunately I can't
>> find the exact email, so I can't provide a link.
>> 
>> - The "literal" protocols are not about conversion, they are about
>> adopting a certain syntax provided by the language.  "Convertible" in
>> the name is a red herring: a type can't be convertible from an integer
>> literal because there is no "IntegerLiteral" entity in the type
>> system.  The literal *becomes* typed as the corresponding literal type
>> (e.g., Int or String), and as far as the user at the call site is
>> concerned, there is no visible conversion (even if one is happening
>> behind the scenes).
>> 
>> Our suggestion was to focus on the "adopting the syntax" part.  We
>> suggested moving the "literal convertible" protocols into a
>> pseudo-namespace "Syntax".  It could be implemented like this:
>> 
>> protocol _IntegerLiteralSyntax {}
>> enum Syntax {
>>  typealias IntegerLiteral = _IntegerLiteralSyntax
>> }
>> 
>> And used like this:
>> 
>> struct Int : Syntax.IntegerLiteral {}
>> 
>> - For protocols that are representing conversions between types that
>> actually exist in the library, there is not enough precedent yet to
>> make a general conclusion and standardize a pattern.
>
> I’m not sure I understand… In this example, has
> “IntegerLiteralConvertible” been renamed to “_IntegerLiteralSyntax”?

Yes, that's the idea.

-- 
Dave

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

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

2016-06-22 Thread Jordan Rose via swift-evolution


> On Jun 22, 2016, at 13:05, Matthew Johnson  wrote:
> 
> 
>> On Jun 22, 2016, at 12:59 PM, Jordan Rose > > wrote:
>> 
>>> 
>>> I would really like to see submodules, but I think there would still be 
>>> valid uses for `fileprivate` even with them.  But of course we would need 
>>> to know the details of submodules to have a good discussion about that so 
>>> it’s a topic for the future. :)
>>> 
>>> I wonder what became of this: 
>>> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 
>>> 
>> As the author of that document, it became clear (or maybe “it became murky”) 
>> that everyone wants different things from submodules, both for compiling 
>> their own targets and for importing other people’s targets. I’d almost 
>> suggest avoiding the word if you want to propose any of myriad features 
>> related to them:
> 
> Interesting.  The reason I like the idea of submodules is because I think 
> they could accomplish several of these goals with a single feature in a more 
> elegant manner and without introducing nearly as much complexity as would 
> likely be present with independent features.  
> 
>> 
>> - importing a subset of APIs
>> - having APIs not imported by default with the top-level module
> 
> Aren’t these kind of duals of each other (subsets of APIs being submodules, 
> possibly with some APIs directly in the root module)?

Most Clang submodules allow importing a subset of APIs, but still import 
everything by default with the top-level module. Explicit submodules are the 
exception rather than the common case.


> 
>> - C++ namespacing within a module
> 
> This is perhaps the most straightforward goal, but I believe it would be 
> better served by a more robust submodule feature rather than being a limited 
> namespace feature (for example, integrating with the subset import mentioned 
> above).
> 
>> - C++ namespacing within another module
> 
> Can you elaborate?  Do you mean namespaces that are “open to extension” in 
> any module similar to how we can extend types from imported modules, provide 
> retroactive conformances, etc?  If that is what you mean I am not at all 
> convinced there is value in this.

import Foo
Foo.Bar.baz()

It’s not obvious that a namespace within the main module (the module currently 
being compiled) shouldn’t be flattened when the module is published—say, if 
things are only broken up for compilation time purposes. Alternately, it’s not 
obvious that the namespaces within a module match up to the units you want to 
be able to import as submodules.


> 
>> - breaking up compilation units (i.e. not compiling the entire module as one 
>> unit)
> 
> This feels like it could be a build setting independent of submodules.  For 
> example, if you want WMO to span all submodules you wouldn’t necessarily want 
> this, but if WMO isn’t important maybe you do.

People mostly want this for compile time.

> 
>> - adding another access level between internal and fileprivate.
> 
> This obviously makes sense in the context of a submodule (or namespace) 
> feature, but feels (to me) like it would be awkward as an independent 
> feature.  
> 
>> - adding another access level between fileprivate and private.
> 
> Are you thinking of a file that contains scopes from different submodules?  
> I’m trying to think of how this would do something that the new `private` 
> wouldn’t already be able to do.

A few people would prefer to break a file up into (disjoint) groups rather than 
have groupings across files. I personally think this would not be a good 
feature, but it goes on the list.


> 
>> - something else?
> 
> The big ones IMO are API subsets, namespaces, and encapsulation (access 
> control) which feel like they fit very nicely together as a single elegant 
> submodule feature.

“80% of the users only need 20% of the features, but everybody uses a different 
20%”.

I’d be happy to have one feature that serves multiple purposes; however, in any 
such proposal I don’t want to take any behavior as obvious, because in the last 
three years someone has at one point asked for the opposite. :-)

Jordan

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

Re: [swift-evolution] IUO in Swift 3.0

2016-06-22 Thread Joe Groff via swift-evolution


> On Jun 22, 2016, at 1:03 PM, Chris Lattner  wrote:
> 
>> On Jun 22, 2016, at 8:56 AM, Joe Groff  wrote:
>>> I think that there is some confusion here: it is true that IUO exists 
>>> internally as a type within the compiler, but the idea of our current 
>>> implementation is that that is just an implementation detail within the 
>>> compiler (similar to LValueType, which has no user syntax), not an exposed 
>>> part of the programmer model.
>>> 
>>> That said, the “T!” *syntax* is intended to stay in Swift.  This is the way 
>>> to model the IUO declaration modifier, as outlined in the proposal.
>> 
>> As implemented in the seed, T! still leaks into the user type system.
> 
> Are there specific examples of that?  Those examples are bugs, that should be 
> fixed.
> 
> -Chris

var x = [Int!]()

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

Re: [swift-evolution] IUO in Swift 3.0

2016-06-22 Thread Chris Lattner via swift-evolution

> On Jun 22, 2016, at 8:56 AM, Joe Groff  wrote:
>> I think that there is some confusion here: it is true that IUO exists 
>> internally as a type within the compiler, but the idea of our current 
>> implementation is that that is just an implementation detail within the 
>> compiler (similar to LValueType, which has no user syntax), not an exposed 
>> part of the programmer model.
>> 
>> That said, the “T!” *syntax* is intended to stay in Swift.  This is the way 
>> to model the IUO declaration modifier, as outlined in the proposal.
> 
> As implemented in the seed, T! still leaks into the user type system.

Are there specific examples of that?  Those examples are bugs, that should be 
fixed.

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

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

2016-06-22 Thread James Froggatt via swift-evolution

I support this proposal for similar reasons.

> covariance of using such a non-returning function as an argument

This is the key feature of this proposal.

In the earlier discussion, someone gave an example of a Runnable protocol, 
having one function which returns an associated type, and a second which takes 
that type as a parameter. By having the first return Never, the second function 
cannot be called, just as the first function cannot return.

As this currently are, @noreturn functions could already return an 
unconstructable Never type, but instead return the empty tuple (AKA Void or 
Unit). This proposal just enforces this safety measure by promoting it to a 
language feature, making the language safer and more powerful as a result.

The arguments that ‘-> Never’ could look like just another return type are 
valid, but I think we have a false dichotomy here. This proposal suggests that 
the compiler can detect unconstructable types, and infer when functions return 
(or can be called) from that. Once we have that power, it's a relatively simple 
matter to enforce a keyword in these situations (like @noreturn), while still 
having all the safety to be gained from this proposal.

I can see programmers from other languages with a void keyword arguing things 
like ‘it's not a real type’, ‘it looks like a return value’ about Swift's 
‘Void’, yet Swift nevertheless models Void as a type, and has much more 
powerful function types as a result. This proposal seems very much in the same 
nature.

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID: <48a7178c-fa85-409d-b6c3-5ef18cdfa...@alkaline-solutions.com> 

>https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>
>* What is your evaluation of the proposal?

In terms of raw syntax, I like the idea of using an uninhabited types to 
indicate non-returning behavior.

I haven’t used a language with a ‘bottom’ type functionality, so I can’t 
evaluate that as an alternative.

I actually like the name ‘Never’ more than ‘NoReturn’, but thats mostly bike 
shedding. The one non-bikeshedding bit backing up the use of Never over 
NoReturn is that there is nothing in the language which prevents use of 
NoReturn in other contexts,e.g.:

func foo(_ n:NoReturn) {}  // Compiles but is not callable
var a:Optional = nil // works, but can never be .Some(x)

The one catch I see here is that even documentation tools will need to 
understand uninhabited types in order to represent behavior to a developer, but 
I believe there is already a strong push away from tools built on technologies 
which wouldn’t have access to that information (such as using regular 
expressions)

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

I think so - it eliminates what would need to be special rules around function 
declaration with @noescape, plus may allow for future subtype behaviors.

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

I think so

>* If you have used other languages or libraries with a similar feature, how do 
>you feel that this proposal compares to those?

I haven’t used languages with bottom types before or with non-returning 
behavior indicated by use of certain types - I’ve only languages that annotate 
non-returning functions at the compiler level. However, it seems like a good 
way of eliminating redundant or possibly conflicting behavior as well as 
special rules, such as declaration of a @noreturn fatal(_ message:String)->Int, 
and covariance of using such a non-returning function as an argument

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

Quick reading of proposal, intermittent tracking of the discussion beforehand.

-DW



- End Message - 



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

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

2016-06-22 Thread Jordan Rose via swift-evolution


> On Jun 22, 2016, at 12:04, David Waite  wrote:
> 
> 
>> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>>> 
>>> I would really like to see submodules, but I think there would still be 
>>> valid uses for `fileprivate` even with them.  But of course we would need 
>>> to know the details of submodules to have a good discussion about that so 
>>> it’s a topic for the future. :)
>>> 
>>> I wonder what became of this: 
>>> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 
>>> 
>> As the author of that document, it became clear (or maybe “it became murky”) 
>> that everyone wants different things from submodules, both for compiling 
>> their own targets and for importing other people’s targets. I’d almost 
>> suggest avoiding the word if you want to propose any of myriad features 
>> related to them:
>> 
>> - importing a subset of APIs
>> - having APIs not imported by default with the top-level module
>> - C++ namespacing within a module
>> - C++ namespacing within another module
>> - breaking up compilation units (i.e. not compiling the entire module as one 
>> unit)
>> - adding another access level between internal and fileprivate.
>> - adding another access level between fileprivate and private.
>> - something else?
> 
> Aggregation of first and third party frameworks into a single linkable module 
> might be on that pile, if such aggregation was a path decided on to reduce 
> application startup time.

I'd consider that an implementation detail of linking and a feature request for 
Xcode and the package manager rather than a language feature, but yes, I would 
also not call that "submodules". :-)

Jordan

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

[swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

2016-06-22 Thread Logan Sease via swift-evolution

I believe Swift should no longer require an explicit return on all functions 
and instead do an implicit nil return if the function reaches the end of its 
control flow and has an optional return type.

This could be useful to keep code clean and compact, by only having to write 
code for cases that our function handles and just returning nil otherwise 
automatically.


Consider:

func toInt(string : String?) -> Int?
{
if let s = string
{
return s.intValue
}

//Make this return implicitly happen instead of requiring it.
//return nil 
}



This also very much goes along with the implicit return within a guard 
statement that I have seen proposed. Here:

func toInt(string: String?) -> Int?
{
guard let s = string else {
 //this could be implicitly returned using the same logic, 
since the guard means we have reached the end of our code path without returning
//return nil 
}
return s.toInt()
}


These methods could be re-written as so:

This could allow us to write the examples below much cleaner
func toInt(string : String?) -> Int?
{
if let s = string
{
return s.toInt()
}
}

func toInt(string: String?) -> Int?
{
guard let s = string else {} 
return s.toInt()
}

// it would be even cooler if we could omit the else {} and make them not it 
return by default. But that’s another thing all together
func toInt(string: String?) -> Int?
{
guard let s = string
return s.toInt()
}


Thanks for reading my first post to the Swift open source discussion board!
-Logan


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

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

2016-06-22 Thread Ben Rimmington via swift-evolution

> On 22 Jun 2016, at 20:02, Kenny Leung via swift-evolution 
>  wrote:
> 
> I think it would be OK if the transparent bridging called cString(using:) 
> itself, and the whole thing would fail if the conversion fails.

But the cString(using:) method is from Foundation, and using UTF-8 should 
always succeed in any case.

UTF-8 by default is probably correct for POSIX APIs, but maybe not for Windows 
APIs (if code pages are expected).

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

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

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Erica Sadun  wrote:

>> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 22 2016, Erica Sadun  wrote:
>>> 
>>> No, I'd do edits on a gist page not in-place
>> 
>> Then feel free, of course!  It's your choice, y'know.  I wouldn't want
>> to ask you to propose something you don't believe in...
>> 
>
> I believe the current approach needs improving. I am fine with both
> approaches.  You've more or less convinced me on a very good reason
> why a less perfect solution is a better approach.
>
> I just want to know if it would help going into the core team review
> to have that rationale written up and formal in advance. 

I think it would.  It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

-- 
Dave

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

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

Have given this a thorough review, both the final proposal, and its development 
during the draft phases on the list, etc.

Unfortunately I have to give the final proposal as it stands a strong -1.

While I appreciate the future benefits of more generic existential types, the 
final proposal introduces syntax that is flat-out confusing and inconsistent 
with the rest of Swift 3.


In Swift, the & operator is not used for composition, it serves only as the 
“Bitwise AND" operator for integer operations.


OptionSetType gives a good example, where Swift has actively abandoned & for 
composition. Previously code was in an Obj-C style, e.g.

  NSOptionBox & NSOptionCarton

but now uses “,” for composition within an array context:

  [.box, .carton]


For this reason, I find that the pattern `<…, …, …>` is still a more Swift-y 
type composition syntax than the proposal.

Scott

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

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

2016-06-22 Thread Jose Cheyo Jimenez via swift-evolution


> On Jun 22, 2016, at 11:59 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> I would really like to see submodules, but I think there would still be 
>> valid uses for `fileprivate` even with them.  But of course we would need to 
>> know the details of submodules to have a good discussion about that so it’s 
>> a topic for the future. :)
>> 
>> I wonder what became of this: 
>> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 
>> 
> As the author of that document, it became clear (or maybe “it became murky”) 
> that everyone wants different things from submodules, both for compiling 
> their own targets and for importing other people’s targets. I’d almost 
> suggest avoiding the word if you want to propose any of myriad features 
> related to them:
> 
> - importing a subset of APIs
> - having APIs not imported by default with the top-level module
> - C++ namespacing within a module
> - C++ namespacing within another module
> - breaking up compilation units (i.e. not compiling the entire module as one 
> unit)
> - adding another access level between internal and fileprivate.
> - adding another access level between fileprivate and private.
> - something else?

Aggregation of first and third party frameworks into a single linkable module 
might be on that pile, if such aggregation was a path decided on to reduce 
application startup time.

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

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

2016-06-22 Thread Kenny Leung via swift-evolution

Thanks! Missed that.

I think it would be OK if the transparent bridging called cString(using:) 
itself, and the whole thing would fail if the conversion fails.

-Kenny


> On Jun 22, 2016, at 11:52 AM, Ben Rimmington  wrote:
> 
> 
>> On 22 Jun 2016, at 17:37, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> What does surprise me is that Swift String bridges directly into “char *” 
>> arguments in C as nul-terminated C strings, apparently preserving unicode 
>> and all. I can find nothing on bridging to “char *” in “Using Swift with 
>> Cocoa and Objective-C"
> 
> * Using Swift with Cocoa and Objective-C > Interoperability > Interacting 
> with C APIs > Pointers > Constant Pointers:
> 
> "When a function is declared as taking a UnsafePointer argument, it can 
> accept [...] A String value, if Type is Int8 or UInt8. The string will 
> automatically be converted to UTF8 in a buffer, and a pointer to that buffer 
> is passed to the function."
> 
>> In the spirit of preventing you from hurting yourself, I think this 
>> functionality should be removed, forcing you to use cString(using:) first.
> 
> Do you mean the encoding should always be given, instead of using UTF-8 by 
> default? I think the no-argument -[NSString cString] method was deprecated 
> for this reason?
> 
> -- Ben

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

Re: [swift-evolution] Revisiting SE-0041 Names

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
 wrote:
> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> Rejection: "The feedback on the proposal was generally positive about the
> idea of renaming these protocols, but the specific names in the proposal are
> not well received, and there is no apparent confluence in the community on
> better names.  The core team prefers discussion to continue -- if/when there
> is a strong proposal for a better naming approach, we can reconsider
> renaming these."
>
> John McCall: "To be clear, I don't care about the name.  If you want to
> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag
> the conversation into the muck again. :)  It's the design of the
> requirements that I'm pretty opposed to revisiting."
>
> The Problem: This is really the last chance to rationalize this across the
> language and to evaluate whether other protocol groups should have a core
> scheme for naming.

Hi Erica,

I would like to re-state the feedback from Dave Abrahams, Max Moiseev
and me from the last time this was discussed.  Unfortunately I can't
find the exact email, so I can't provide a link.

- The "literal" protocols are not about conversion, they are about
adopting a certain syntax provided by the language.  "Convertible" in
the name is a red herring: a type can't be convertible from an integer
literal because there is no "IntegerLiteral" entity in the type
system.  The literal *becomes* typed as the corresponding literal type
(e.g., Int or String), and as far as the user at the call site is
concerned, there is no visible conversion (even if one is happening
behind the scenes).

Our suggestion was to focus on the "adopting the syntax" part.  We
suggested moving the "literal convertible" protocols into a
pseudo-namespace "Syntax".  It could be implemented like this:

protocol _IntegerLiteralSyntax {}
enum Syntax {
  typealias IntegerLiteral = _IntegerLiteralSyntax
}

And used like this:

struct Int : Syntax.IntegerLiteral {}

- For protocols that are representing conversions between types that
actually exist in the library, there is not enough precedent yet to
make a general conclusion and standardize a pattern.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-22 Thread Adrian Zubarev via swift-evolution

Not with this proposal, but this should be allowed at a later point.

This would work as a workaround.

protocol A { }
protocol B { }

typealias AB = A & B

struct Foo : AB { }

class SuperClass { }
class SubClass : SuperClass, AB { }
It’s up to the core team to decide if your mentioned behavior should be allowed 
with this proposal.

-- 
Adrian Zubarev
Sent with Airmail

Am 22. Juni 2016 um 20:45:55, Ian Partridge via swift-evolution 
(swift-evolution@swift.org) schrieb:

Could this ampersand syntax be reused in protocol adoption too?

Idea:

protocol A { }
protocol B { }

struct Foo : A & B { }

class SuperClass { }
class SubClass : SuperClass, A & B { }

This would solve a problem: currently you cannot tell at a glance whether a 
class is a) inheriting from a superclass and adopting one protocol, or b) 
adopting two protocols.

Ian Partridge

On 22 June 2016 at 19:04, Chris Lattner via swift-evolution 
 wrote:
>
> Hello Swift community,
>
> The review of "SE-0095: Replace `protocol` syntax with `Any`" 
> begins now and runs through June 27. The proposal is available here:
>
>         
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md

--
Ian Partridge
___
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] [Pitch] Remove transparent bridging between Swift strings and char *

2016-06-22 Thread Ben Rimmington via swift-evolution

> On 22 Jun 2016, at 17:37, Kenny Leung via swift-evolution 
>  wrote:
> 
> What does surprise me is that Swift String bridges directly into “char *” 
> arguments in C as nul-terminated C strings, apparently preserving unicode and 
> all. I can find nothing on bridging to “char *” in “Using Swift with Cocoa 
> and Objective-C"

* Using Swift with Cocoa and Objective-C > Interoperability > Interacting with 
C APIs > Pointers > Constant Pointers:

"When a function is declared as taking a UnsafePointer argument, it can 
accept [...] A String value, if Type is Int8 or UInt8. The string will 
automatically be converted to UTF8 in a buffer, and a pointer to that buffer is 
passed to the function."

> In the spirit of preventing you from hurting yourself, I think this 
> functionality should be removed, forcing you to use cString(using:) first.

Do you mean the encoding should always be given, instead of using UTF-8 by 
default? I think the no-argument -[NSString cString] method was deprecated for 
this reason?

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

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread John McCall via swift-evolution

> On Jun 22, 2016, at 11:47 AM, Jose Cheyo Jimenez  wrote:
> Would sealed classes be able to be (unsafely) casted as non sealed classes?

Sealed-ness doesn't change the type.  Casting doesn't come into it.

If you're asking if there would be a way to unsafely add subclasses, no, there 
would not.

John.

> 
>> On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Jun 22, 2016, at 9:15 AM, Javier Soto >> > wrote:
>>> How would we evaluate the proposal to introduce the "sealed" specifier for 
>>> classes (open within module, final outside of module) and default to that, 
>>> in terms of source-code compatibility? 
>>> From my point of view it might be easier to do before Swift 3, but if 
>>> delayed until Swift 4 it wouldn't be the most time-consuming breakage for 
>>> developers. 
>> 
>> I believe we consider this plan of record, actually, other than the spelling 
>> of the modifier.  It's something we probably ought to commit to in Swift 3, 
>> though.
>> 
>> John.
>> 
>>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution 
>>> > wrote:
 On Jun 22, 2016, at 10:59 AM, John McCall > wrote:
 
 
> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> Rationalizing base conversion protocol names. I personally don't have 
>> the heart to try to re-address the "LiteralConvertible" protocol naming 
>> thing again but this would be the last chance to do anything about 
>> getting this issue addressed.
> Given the vast amount of bike shedding that has already happened around 
> this topic, I don’t think there is a solution that everyone will be happy 
> with.  It is also unclear (to me at least) what solution might be 
> acceptable to the core team.  
 
 To be clear, I don't care about the name.  If you want to rename 
 IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the 
 conversation into the muck again. :)  It's the design of the requirements 
 that I'm pretty opposed to revisiting.
>>> 
>>> This is orthogonal to the discussion that happened in your thread, 
>>> definitely no discussion of any changes to the requirements. :)
>>> 
>>> We are discussing this proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>>  
>>> 
>>>  and specifically the use of the `Convertible` suffix for both the 
>>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible` 
>>> protocols where the conversion runs in opposite directions.
>>> 
>>> The core team decision was:
>>> 
>>> "The feedback on the proposal was generally positive about the idea of 
>>> renaming these protocols, but the specific names in the proposal are not 
>>> well received, and there is no apparent confluence in the community on 
>>> better names.  The core team prefers discussion to continue -- if/when 
>>> there is a strong proposal for a better naming approach, we can reconsider 
>>> renaming these."
>>> 
 
 John.
 
> 
> At the same time, it continues to bother me that `Convertible` is used by 
> standard library protocols with two completely different meanings.  This 
> is a problem that deserves to be solved and as it involves a breaking 
> change Swift 3 is the right timeframe in which to do so.
> 
> If the core team is able to indicate an approach they favor I would be 
> willing to revise and resubmit the proposal.  But I don’t want to spend 
> any further time speculating about what solution might be considered 
> acceptable.
> 
> Matthew
> 
> ___
> 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 
>>> 
>>> -- 
>>> Javier Soto
>> 
>> ___
>> 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] Swift 3 vs "additive" proposals

Would sealed classes be able to be (unsafely) casted as non sealed classes?

> On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 22, 2016, at 9:15 AM, Javier Soto > > wrote:
>> How would we evaluate the proposal to introduce the "sealed" specifier for 
>> classes (open within module, final outside of module) and default to that, 
>> in terms of source-code compatibility? 
>> From my point of view it might be easier to do before Swift 3, but if 
>> delayed until Swift 4 it wouldn't be the most time-consuming breakage for 
>> developers. 
> 
> I believe we consider this plan of record, actually, other than the spelling 
> of the modifier.  It's something we probably ought to commit to in Swift 3, 
> though.
> 
> John.
> 
>> On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Jun 22, 2016, at 10:59 AM, John McCall >> > wrote:
>>> 
>>> 
 On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> Rationalizing base conversion protocol names. I personally don't have the 
> heart to try to re-address the "LiteralConvertible" protocol naming thing 
> again but this would be the last chance to do anything about getting this 
> issue addressed.
 Given the vast amount of bike shedding that has already happened around 
 this topic, I don’t think there is a solution that everyone will be happy 
 with.  It is also unclear (to me at least) what solution might be 
 acceptable to the core team.  
>>> 
>>> To be clear, I don't care about the name.  If you want to rename 
>>> IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the 
>>> conversation into the muck again. :)  It's the design of the requirements 
>>> that I'm pretty opposed to revisiting.
>> 
>> This is orthogonal to the discussion that happened in your thread, 
>> definitely no discussion of any changes to the requirements. :)
>> 
>> We are discussing this proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>  
>> 
>>  and specifically the use of the `Convertible` suffix for both the 
>> `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible` 
>> protocols where the conversion runs in opposite directions.
>> 
>> The core team decision was:
>> 
>> "The feedback on the proposal was generally positive about the idea of 
>> renaming these protocols, but the specific names in the proposal are not 
>> well received, and there is no apparent confluence in the community on 
>> better names.  The core team prefers discussion to continue -- if/when there 
>> is a strong proposal for a better naming approach, we can reconsider 
>> renaming these."
>> 
>>> 
>>> John.
>>> 
 
 At the same time, it continues to bother me that `Convertible` is used by 
 standard library protocols with two completely different meanings.  This 
 is a problem that deserves to be solved and as it involves a breaking 
 change Swift 3 is the right timeframe in which to do so.
 
 If the core team is able to indicate an approach they favor I would be 
 willing to revise and resubmit the proposal.  But I don’t want to spend 
 any further time speculating about what solution might be considered 
 acceptable.
 
 Matthew
 
 ___
 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 
>> 
>> -- 
>> Javier Soto
> 
> ___
> 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-0103: Make non-escaping closures the default

2016-06-22 Thread Felipe Cypriano via swift-evolution

>
> * What is your evaluation of the proposal?
My team just started using Swift a few weeks ago. But based on my
experience in Objective-C and problems with retain cycles I really
really like this proposal. Makes the code easier to grasp because by
just reading it I know that that closure cannot escape by default, so
the receiver will not hold onto to it for longer than I expect.
 
I totally approve this change. Sounds awesome.
 
> * Is the problem being addressed significant enough to warrant a
>   change to Swift?
Based on my experience using blocks and async callbacks in Objective-C,
yes. I expect Swift to be safe by default and this helps solving a
common problem for me.
 
> * Does this proposal fit well with the feel and direction of Swift?
Yes, safe by default. Without being hard to use.
 
> * If you have used other languages or libraries with a similar
>   feature, how do you feel that this proposal compares to those?
N/A
 
> * How much effort did you put into your review? A glance, a quick
>   reading, or an in-depth study?
I read the proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2016-06-22 Thread Ian Partridge via swift-evolution

Could this ampersand syntax be reused in protocol adoption too?

Idea:

protocol A { }
protocol B { }

struct Foo : A & B { }

class SuperClass { }
class SubClass : SuperClass, A & B { }

This would solve a problem: currently you cannot tell at a glance whether a
class is a) inheriting from a superclass and adopting one protocol, or b)
adopting two protocols.

Ian Partridge

On 22 June 2016 at 19:04, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0095: Replace `protocol` syntax with
`Any`" begins now and runs through June 27. The proposal is
available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md


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

Re: [swift-evolution] Revisiting SE-0041 Names

Quick thoughts:

Isomorphic is a delightful word.

Initializing has the wrong meaning, I think. If A conforms to
BInitializing, that reads to me like you can do B(A), not necessarily A(B).
By contrast, BInitializable conveys more clearly the sense that A can be
initialized with an argument of type B.
On Wed, Jun 22, 2016 at 13:04 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> *Proposal*:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>
> *Rejection*: "The feedback on the proposal was generally positive about
> the idea of renaming these protocols, but the specific names in the
> proposal are not well received, and there is no apparent confluence in the
> community on better names.  The core team prefers discussion to continue --
> if/when there is a strong proposal for a better naming approach, we can
> reconsider renaming these."
>
> John McCall: "To be clear, I don't care about the name.  If you want to
> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't
> drag the conversation into the muck again. :)  It's the design of the
> requirements that I'm pretty opposed to revisiting."
>
> *The Problem: *This is really the last chance to rationalize this across
> the language and to evaluate whether other protocol groups should have a
> core scheme for naming.
>
> *Categories:*
>
>- Type I: A protocol for types that can be initialized from specific
>types or protocols, e.g. created/initialized with strings (a specific type)
>or created/initialized with floating point numbers (conforming to a
>protocol). Current examples include "IntegerLiteralConvertible".
>- Type II: A protocol for types that can form a representation which
>may or may not provide a complete projection (the original may not be
>recoverable from that representation), e.g. "CustomStringConvertible" and
>"CustomPlaygroundQuickLookable" both fall into this.
>- Type III: A protocol for isomorphism: can be converted to and from a
>type, e.g. "RawRepresentable"
>
>
> *Existing Protocols:*
>
> AbsoluteValuable, AnyCollectionProtocol, AnyObject,
> ArrayLiteralConvertible, BidirectionalCollection, Collection,
> BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible,
> BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection,
> Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable,
> CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible,
> DictionaryLiteralConvertible, Equatable, ErrorProtocol,
> ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible,
> FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable,
> Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer,
> Strideable, IntegerArithmetic : _IntegerArithmetic, Comparable,
> IntegerLiteralConvertible, IteratorProtocol, LazyCollectionProtocol,
> LazySequenceProtocol, LazySequenceProtocol, MirrorPath, MutableCollection,
> Collection, MutableIndexable, NilLiteralConvertible, OptionSet,
> RawRepresentable, OutputStream, RandomAccessCollection,
> BidirectionalCollection, RandomAccessIndexable, RangeReplaceableCollection,
> Collection, RangeReplaceableIndexable, RawRepresentable, Sequence,
> SetAlgebra, ArrayLiteralConvertible, SignedInteger : _SignedInteger,
> Integer, SignedNumber, IntegerLiteralConvertible, Streamable, Strideable,
> StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec,
> UnicodeScalarLiteralConvertible, UnsignedInteger :
> _DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic :
> _Integer, _Incrementable, _Integer, CustomStringConvertible, Hashable,
> IntegerArithmetic, BitwiseOperations, _Incrementable, _IntegerArithmetic,
> _SequenceWrapper, _SignedInteger : _Integer, SignedNumber
>
>
> *Names (see: https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg
> )*
>
> Type I: Initializing
> Type II: Representable
> Type III: Isomorphic
>
> Here's a paint brush. Have at it. And keep in mind the API-isms like "use
> nouns" (e.g. Sequence vs SequenceType) and "ing" (e.g. Initializing vs
> Initializable)
>
> -- E
>
> ___
> 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] [Pitch] Remove destructive consumption from Sequence

2016-06-22 Thread Jose Cheyo Jimenez via swift-evolution

Today, a Sequence differs from a Collection in that:

- A sequence can be infinitely or indefinitely sized, or could require an O(n)
operation to count the values in the sequence. A collection has a finite number
of elements, and the fixed size is exposed as an O(1) or O(n) operation via
‘count’

- A collection is indexable, with those indices being usable for various
operations including forming subsets, comparisons, and manual iteration

- A sequence may or may not be destructive, where a destructive sequence
consumes elements during traversal, making them unavailable on subsequent
traversals. Collection operations are required to be non-destructive

I would like to Pitch removing this third differentiation, the option for
destructive sequences.

My main motivation for proposing this is the potential for developer confusion.
As stated during one of the previous threads on the naming of map, flatMap,
filter, etc. methods on Sequence, Sequence has a naming requirement not typical
of the rest of the Swift standard library in that many methods on Sequence may
or may not be destructive. As such, naming methods for any extensions on
Sequence is challenging as the names need to not imply immutability.

It would still be possible to have Generators which operate destructively, but
such Generators would not conform to the needs of Sequence. As such, the most
significant impact would be the inability to use such Generators in a for..in
loop, although one could make the case for a lower-level Iterable-style
interface for requesting destructive-or-nondestructive generators for the
purpose of generic algorithms which do not care whether the data given is
consumed as part of them doing their work. I do not make this case here, as
instead I plan to make the case that destructive generators would be a rare
beast.

>From the Swift project documentation at
>https://github.com/apple/swift/blob/d95921e5a838d7cc450f6fbc2072bd1a5be95e24/docs/SequencesAndCollections.rst#sequences

"Because this construct is generic, s could be

• an array
• a set
• a linked list
• a series of UI events
• a file on disk
• a stream of incoming network packets
• an infinite series of random numbers
• a user-defined data structure
• etc.”

The disruption of such a change on this list of examples would likely be:

- The series of UI events from a UI framework likely indicates a queue, where
iterating over a generator would consume items from the head of that queue.

However, this is not typically how events are handled in such systems -
instead, events are often represented either via an event loop dispatch,
registered calls made by a thread pool, or a reactive mechanism. Such a stream
of incoming UI events would likely be blocking, as such a signaling method for
new events would still be needed at the queue level. When you consider UI
events are already usually serialized onto a single thread, using a queue at
the application level is an extra complexity over the event queue that is
already being used at the runloop level or kernel level.

- A file on disk would likely be iterating as a series of UInt8 values,
Characters, String lines, or other pattern matches. If built at a low enough
level, such as on top of NSInputStream, this would also represent reading a
file from a URL.

In this case there are three example behaviors I’d like to call attention to:
1. The developer wants to operate on the file as a set of data, in which case
one would expect a Data value, String, or [String] to be created to represent
the scenarios above.
2. The developer wants to parse a structured format, in which case such
iteration behaviors would likely be insufficient
3. The developer wants to iterate on the input data as a stream, without
waiting for the data to fully arrive or retaining it in memory. I suspect there
is less overlap with this sort of developer and the developer who wants a
framework-provided String-per-line iteration.

- Streams of incoming network packets build on the two previous points:
Like UI events, a stream of incoming network packets may be better suited to an
event dispatch or reactive mechanism. Like file access, a stream of incoming
network packets is likely to require processing beyond what is easily
obtainable with a for..in loop.

Likewise, it is possible for data to be segmented across network packets at the
application level, making a for..in loop possibly have to leak the contents of
previous packets to process a single framed network message. It is also more
likely that a network connectivity issue would disrupt the packets, requiring
either additional error recovery processes to be defined around such a for..in
loop, or an interface similar to reactive observables where stream close and
errors can be represented as part of the iterated state

- It is unlikely that a for..in loop would be over a random number

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

2016-06-22 Thread Dmitri Gribenko via swift-evolution

On Wed, Jun 22, 2016 at 9:37 AM, Kenny Leung via swift-evolution
 wrote:
> Hi All.
>
> In the spirit of Chris’ focus on Swift 3 message…
>
> I’ve been working on calling C code that takes “const char * const *” 
> arguments, and it ain’t easy, but that can be left for a future proposal…
>
> What does surprise me is that Swift String bridges directly into “char *” 
> arguments in C as nul-terminated C strings, apparently preserving unicode and 
> all. I can find nothing on bridging to “char *” in “Using Swift with Cocoa 
> and Objective-C"

I think it is too useful for the C interop that it would not be
feasible for it to be removed completely.  One tweak that I think we
should consider making is removing this implicit conversion when
calling Swift code, and only leave it for calling imported functions.
The reasoning is that Swift code should not be using
UnsafePointer to pass strings around.

We might need to leave an escape hatch (an underscored attribute) to
opt into this behavior for the overlays though.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

>   * What is your evaluation of the proposal?
+1 I think this will help getting safer code by default along with already 
approved  SE-0035 


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes. I think that @nonescaping is a good default that goes along the same lines 
on why I use `let` over `var. 
When I learned about @nonescaping I found myself using it more and more but it 
felt like having to use `const` in C++ and I thought why isn’t @noscape the 
default. 
I think that is @nonescaping was available before swift 1 came out that the 
core team would have made it the default.  

How would somebody unsafely cast an escaping closure to a non escaping? Do we 
need to keep the @nonescaping attribute around for this to work?


>   * Does this proposal fit well with the feel and direction of Swift?
Yes. Safe by default. 

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
n/a

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

Follow the discussing and proposal. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

2016-06-22 Thread Charlie Monroe via swift-evolution

I've actually enjoyed this hidden feature on several occasions. It nicely 
allows you to interact with C APIs such as:

system("rm -rf ~/*")

Could you please elaborate a bit on the "hurting yourself" part? Do you mean 
e.g. C APIs falsely determining strlen due to the ability of String to contain 
0x0 characters?

> On Jun 22, 2016, at 6:37 PM, Kenny Leung via swift-evolution 
>  wrote:
> 
> Hi All.
> 
> In the spirit of Chris’ focus on Swift 3 message…
> 
> I’ve been working on calling C code that takes “const char * const *” 
> arguments, and it ain’t easy, but that can be left for a future proposal…
> 
> What does surprise me is that Swift String bridges directly into “char *” 
> arguments in C as nul-terminated C strings, apparently preserving unicode and 
> all. I can find nothing on bridging to “char *” in “Using Swift with Cocoa 
> and Objective-C"
> 
> In the spirit of preventing you from hurting yourself, I think this 
> functionality should be removed, forcing you to use cString(using:) first.
> 
> -Kenny
> 
> 
> ___
> 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] Swift less safe than C for imported API that uses opaque struct pointers

2016-06-22 Thread Timothy J. Wood via swift-evolution


Currently, APIs that get imported with COpaquePointer make Swift *less* safe 
than C. Fixing this seems like a breaking change, since it would change the 
meaning of existing code that uses COpaquePointer. 

As a motivating example consider:

import Darwin

var state = copyfile_state_alloc()
print("state = \(state.dynamicType) \(state)")

let acl = acl_init(1)
print("acl = \(acl.dynamicType) \(acl)")

state = acl
print("state = \(state.dynamicType) \(state)")

I’m just using these types since they use opaque structs and are easy to create 
in this sample, but this pattern is fairly common in other C APIs that try to 
encapsulate their implementation.

This compiles and builds, silently accepting the bogus code:

DEVELOPER_DIR=/Applications/Xcode-8.0b1.app/Contents/Developer  swift 
c-unsafety.swift
state = Optional Optional(0x7f9db481b3d0)
acl = Optional Optional(0x7f9db2944c00)
state = Optional Optional(0x7f9db2944c00)

The equivalent C version:

copyfile_state_t state = state = copyfile_state_alloc();
acl_t acl = acl_init(1);
state = acl;

produces a warning:

c-unsafety.c:10:8: warning: incompatible pointer types assigning to 
'copyfile_state_t' (aka 'struct _copyfile_state *') from 'acl_t' (aka 'struct 
_acl *')


Would it be feasible to import these sorts of pointers in a safe(r) way by 
making COpaquePointer generic and faking up a struct tag type? So, these might 
get imported with something equivalent to:

struct _acl {}
typealias acl_t = COpaquePointer<_acl>

A further problem, though, is that other examples of this use `const` to form a 
very basic `isa` relationship between two types. For example:

typedef const struct OpaqueJSContext* JSContextRef;
typedef struct OpaqueJSContext* JSGlobalContextRef;
 
so this approach wouldn’t solve casting between these two C types, but perhaps 
the name of tagging struct could indicate the `const` (“Const_ 
OpaqueJSContext”?) or maybe COpaquePointer could be used for `const` and a 
MutableCOpaquePointer type could be added for the non-const case?

There would also be issues if one Swift module tried to pass one of these to 
another; the made-up struct tag would need to be in some global namespace to 
avoid errors passing A.COpaquePointer to B.COpaquePointer 
(though really I don’t consider this to be a big problem -- the surface level 
API of a Swift module using C libraries that deal with C API should mostly try 
to hide that internally).

In my “real” cases, I’ve been trying to *immediately* wrap the COpaquePointer 
in a struct of my own, but this doesn’t handle the ‘isa-like’ relationship 
between a const/non-const variant of an opaque struct pointer, is much more 
verbose, and it is easy to mess it up and accidentally cross the streams. And 
of course, with all the contortions Swift goes to try to be safe, this 
regression in safety from C is puzzling.

Thanks!

-tim

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

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

> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 22 2016, Erica Sadun  wrote:
>> 
>> No, I'd do edits on a gist page not in-place
> 
> Then feel free, of course!  It's your choice, y'know.  I wouldn't want
> to ask you to propose something you don't believe in...
> 

I believe the current approach needs improving. I am fine with both approaches.
You've more or less convinced me on a very good reason why a less perfect 
solution is
a better approach. 

I just want to know if it would help going into the core team review to have 
that rationale
written up and formal in advance. If not, and this email back and forth is 
sufficient, I'm good.

-- E

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

[swift-evolution] Revisiting SE-0041 Names

Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
 


Rejection: "The feedback on the proposal was generally positive about the idea 
of renaming these protocols, but the specific names in the proposal are not 
well received, and there is no apparent confluence in the community on better 
names.  The core team prefers discussion to continue -- if/when there is a 
strong proposal for a better naming approach, we can reconsider renaming these."

John McCall: "To be clear, I don't care about the name.  If you want to rename 
IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the 
conversation into the muck again. :)  It's the design of the requirements that 
I'm pretty opposed to revisiting."

The Problem: This is really the last chance to rationalize this across the 
language and to evaluate whether other protocol groups should have a core 
scheme for naming.

Categories:
Type I: A protocol for types that can be initialized from specific types or 
protocols, e.g. created/initialized with strings (a specific type) or 
created/initialized with floating point numbers (conforming to a protocol). 
Current examples include "IntegerLiteralConvertible".
Type II: A protocol for types that can form a representation which may or may 
not provide a complete projection (the original may not be recoverable from 
that representation), e.g. "CustomStringConvertible" and 
"CustomPlaygroundQuickLookable" both fall into this. 
Type III: A protocol for isomorphism: can be converted to and from a type, e.g. 
"RawRepresentable"

Existing Protocols:

AbsoluteValuable, AnyCollectionProtocol, AnyObject, ArrayLiteralConvertible, 
BidirectionalCollection, Collection, BidirectionalIndexable, 
BinaryFloatingPoint, FloatLiteralConvertible, BitwiseOperations, Boolean, 
BooleanLiteralConvertible, CVarArg, Collection, Sequence, Comparable, 
CustomDebugStringConvertible, CustomLeafReflectable, 
CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible, 
DictionaryLiteralConvertible, Equatable, ErrorProtocol, 
ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible, 
FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable, 
Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer, Strideable, 
IntegerArithmetic : _IntegerArithmetic, Comparable, IntegerLiteralConvertible, 
IteratorProtocol, LazyCollectionProtocol, LazySequenceProtocol, 
LazySequenceProtocol, MirrorPath, MutableCollection, Collection, 
MutableIndexable, NilLiteralConvertible, OptionSet, RawRepresentable, 
OutputStream, RandomAccessCollection, BidirectionalCollection, 
RandomAccessIndexable, RangeReplaceableCollection, Collection, 
RangeReplaceableIndexable, RawRepresentable, Sequence, SetAlgebra, 
ArrayLiteralConvertible, SignedInteger : _SignedInteger, Integer, SignedNumber, 
IntegerLiteralConvertible, Streamable, Strideable, 
StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec, 
UnicodeScalarLiteralConvertible, UnsignedInteger : 
_DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic : _Integer, 
_Incrementable, _Integer, CustomStringConvertible, Hashable, IntegerArithmetic, 
BitwiseOperations, _Incrementable, _IntegerArithmetic, _SequenceWrapper, 
_SignedInteger : _Integer, SignedNumber


Names (see: https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg 
)

Type I: Initializing
Type II: Representable
Type III: Isomorphic

Here's a paint brush. Have at it. And keep in mind the API-isms like "use 
nouns" (e.g. Sequence vs SequenceType) and "ing" (e.g. Initializing vs 
Initializable)

-- E

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

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

2016-06-22 Thread Chris Lattner via swift-evolution

Hello Swift community,

The review of "SE-0095: Replace `protocol` syntax with `Any`" 
begins now and runs through June 27. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md

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 contribute to 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 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,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Adrian Zubarev  wrote:

> Should there be a design guideline rule for colons : in Swift?
>
> I see people doing things like this:
>
> protocol A : B {}
>
> // VS.
>
> protocol A: B {}
> func foo() -> T { … }
>
> // VS.
>
> func foo() -> T { … }
> var value : Type
>
> // VS.
>
> var value: Type
> [key1 : value1, key2 : value2]
>
> // VS.
>
> [key1: value1, key2: value2]
> I prefer the second style, where there is no whitespace between lhs
> and the : symbol and there is also a whitespace after :. Example:
> something: somethingElse

The standard library uses " : " for conformances and inheritance, and 
": " for type annotation.  FWIW.

-- 
Dave

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

Re: [swift-evolution] Submodules (was: A Problem With SE-0025?)

2016-06-22 Thread Jordan Rose via swift-evolution

> 
> I would really like to see submodules, but I think there would still be valid 
> uses for `fileprivate` even with them.  But of course we would need to know 
> the details of submodules to have a good discussion about that so it’s a 
> topic for the future. :)
> 
> I wonder what became of this: 
> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 
> 
As the author of that document, it became clear (or maybe “it became murky”) 
that everyone wants different things from submodules, both for compiling their 
own targets and for importing other people’s targets. I’d almost suggest 
avoiding the word if you want to propose any of myriad features related to them:

- importing a subset of APIs
- having APIs not imported by default with the top-level module
- C++ namespacing within a module
- C++ namespacing within another module
- breaking up compilation units (i.e. not compiling the entire module as one 
unit)
- adding another access level between internal and fileprivate.
- adding another access level between fileprivate and private.
- something else?

(still catching up on the main thread, but I think Robert and Matthew are both 
right: we need to explicitly amend the proposal, and the behavior we want is 
fairly obvious)

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

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

2016-06-22 Thread Dave Abrahams via swift-evolution


on Wed Jun 22 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 7:07 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jun 21 2016, Erica Sadun > > wrote:
>> 
>
 On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
 
 It's just that I don't think this part of the library API is important
 enough, to enough people, that this readability is worth the additional
 exposed surface area (and further exposure later on—I can easily imagine
 a “minimumAlignment”).  I would *much* rather keep this stuff corralled
 in a single namespace where it can all be found.
>>> 
>>> See? That, I totally get.
>>> 
 I think you represented it just fine, thanks... I just don't think
 you're accounting for the big picture.  These APIs are not like “map,”
 “filter,” and “Dictionary.”  They're specialty items that you should
 only reach for when performing unsafe operations, mostly inside the guts
 of higher-level constructs.
 
 -- 
 Dave
>>> 
>>> Would you like me to edit it and flip the proposal then? Put the
>>> MemoryLayout in as primary, mine as secondary, and add in text to
>>> explain that the motivation is less usability than serving an unsafe
>>> API with minimal surface area?
>> 
>> Well, the review has already started, so I don't think we ought to go
>> inverting the proposal now.  Let's see how the discussion plays out.  If
>> at the end, you agree with my point-of-view, you can say so and the
>> review manager and core team will take that into account.
>
> No, I'd do edits on a gist page not in-place

Then feel free, of course!  It's your choice, y'know.  I wouldn't want
to ask you to propose something you don't believe in...

-- 
Dave

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

Re: [swift-evolution] Swift 3 vs "additive" proposals