Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

[Gwendal Roué via swift-evolution]

> The review of "SE-0052: Change IteratorType post-nil guarantee" begins now 
> and runs through May 3. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md


• What is your evaluation of the proposal?

I'm -1.

I agree with Patrick Pijnappel that it is too easy to write code that assumes 
that iterators end with nil for good, and breaks when this assumption happens 
to be false.

I agree as well that the precondition that when calling next(), no preceding 
call to next() should have returned nil is not observed enough.

I agree that algorithms need guarantees and API contracts.

Yet I have three arguments against the proposal:

1. Obscurity argument: Both the existing precondition, and the proposed 
convention are non-enforceable, non-testable, not well-known enough, and 
generally too weak to be efficient in any way. People don't write custom 
iterators often enough, and I don't expect those rules to eventually percolate 
through Swift culture.

2. Social argument: when a user complains that my library crashes when fed with 
a third-party iterator that does not behave, I, as a library author, have 
better make my code robust and accept non-conforming iterators than whining 
about the third-party. It's just faster and more efficient.

3. Iterator autonomy argument : Iterator is easily seen as a type that exists 
to support Sequence. In this case, we'd like Iterator to end for good (finite 
sequence), or never end (infinite sequence). However, one could argue that 
Iterator is an autonomous type that happens to support Sequence, but may have 
other uses, like message queues. In such a context, requiring post-nil 
guarantees has no meaning.

I'd thus remove the existing precondition, and support the following 
alternatives:

- the FuseIterator Patrick's proposal (and we could discuss its name).
- a new StoppingIterator protocol which does explicitly provide the post-nil 
guarantee. Algorithms could then use this guarantee.


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

Yes, because algorithms need guarantees and API contracts. I'm totally with the 
proposal author here. But I don't think the proposed changes are the right 
solution.


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

This proposal has opened my eyes on a subtle problem with iterators that had 
not yet bitten me in any language I have used before. Or if it had, I guess 
just made my code more robust without much second thought.


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

The best I could to expose my points :-)

Gwendal Roué

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

Re: [swift-evolution] multi-line string literals.

[Cole Campbell via swift-evolution]

I think the proposal is very clear on its intended scope.

I really like this idea. It's readable, and it's as simple and uncluttered as I 
think it could be while still allowing the tabbing of new lines. The one thing 
I dislike about multi line strings in Ruby is how you have to left align each 
new line, which can really disrupt the visual flow of your code, especially if 
you are several tabs of indentation deep.

I would love to see the addition (at some point) of the ability to escape all 
whitespaces preceding the new line, if that line does not begin with a quote 
and thus is meant to be a direct continuation of the preceding line. That way 
you could maintain your indentation without adding whitespaces between what are 
meant to be subsequent characters in the string literal.


On Apr 28, 2016, at 5:52 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Did you ever really use multiline string literals before?
> 
> Yes. I used Perl in the CGI script era. Believe me, I have used every quoting 
> syntax it supports extensively, including `'` strings, `"` strings, `q` 
> strings, `qq` strings, and heredocs. This proposal is educated by knowledge 
> of their foibles.
> 
> As outlined in the "Future directions for string literals in general" 
> section, I believe alternate delimiters (so you can embed quotes) are a 
> separate feature and should be handled in a separate proposal. Once both 
> features are available, they can be combined. For instance, using the 
> `_"foo"_` syntax I sketch there for alternate delimiters, you could say:
> 
>  let xml = _"
>  "
>  " 
>  " \(author)
>  " 
>  ""_
> 
> Basically, I am trying very, *very* hard not to let this proposal turn into 
> "here's a huge pile of random string literal features which will become a 
> giant catfight if we debate them all at once". Clearly this message is not 
> getting through, but I'm not sure how I should edit the proposal to make it 
> clear enough.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] multi-line string literals.

[Vladimir.S via swift-evolution]

@Brent, I suggest to rename the proposal to be clear that it is not trying 
to solve the problem with char escaping i.e. with text *as-is*, that it is 
just removes the  \n"+  from the end of the string. I think many can think 
of "as-is" text feature when starting to read your proposal or will ask 
questions like "why multi-line proposal does not include proposal for as-is 
multi-line", I feel like the title is too generic.


Regarding the proposal itself. I'm ready to support it (in case you'll add 
'specification' of your multi-line feature in the title like "multi-line 
with support of escaping and interpolation", so we can then have another 
proposal like "multi-line without escaping, with text as-is")


One question: what about trailing spaces/tabs in the end of each line? IMO 
there should be one strict rule to prevent any hard-to-find bugs/errors : 
your feature must trim all trailing spaces, or should have an explicit 
marker when to do this or not.


On 29.04.2016 0:56, Brent Royal-Gordon via swift-evolution wrote:

Awesome.  Some specific suggestions below, but feel free to iterate in a
pull request if you prefer that.


I've adopted these suggestions in some form, though I also ended up
rewriting the explanation of why the feature was designed as it is and
fusing it with material from "Alternatives considered".

(Still not sure who I should list as a co-author. I'm currently thinking
John, Tyler, and maybe Chris? Who's supposed to go there?)


  Multiline string literals

  * Proposal: SE-


  * Author(s): Brent Royal-Gordon 
  * Status: *Second Draft*
  * Review manager: TBD



Introduction

In Swift 2.2, the only means to insert a newline into a string literal is
the |\n| escape. String literals specified in this way are generally ugly
and unreadable. We propose a multiline string feature inspired by English
punctuation which is a straightforward extension of our existing string
literals.

This proposal is one step in a larger plan to improve how string literals
address various challenging use cases. It is not meant to solve all
problems with escaping, nor to serve all use cases involving very long
string literals. See the "Future directions for string literals in general"
section for a sketch of the problems we ultimately want to address and some
ideas of how we might do so.

Swift-evolution threads: multi-line string literals. (April)
,
 multi-line
string literals (December)




Draft
Notes

  *

Removes the comment feature, which was felt to be an unnecessary
complication. This and the backslash feature have been listed as future
directions.

  *

Loosens the specification of diagnostics, suggesting instead of
requiring fix-its.

  *

Splits a "Rationale" section out of the "Proposed solution" section.

  *

Adds extensive discussion of other features which wold combine with
this one.

  *

I've listed only myself as an author because I don't want to put anyone
else's name to a document they haven't seen, but there are others who
deserve to be listed (John Holdsworth at least). Let me know if you
think you should be included.



Motivation

As Swift begins to move into roles beyond app development, code which needs
to generate text becomes a more important use case. Consider, for instance,
generating even a small XML string:

let xml = "\n\n\t\n\t\t\(author)\n\t\n"

The string is practically unreadable, its structure drowned in escapes and
run-together lines; it looks like little more than line noise. We can
improve its readability somewhat by concatenating separate strings for each
line and using real tabs instead of |\t| escapes:

let xml = "\n" +
  "\n" +
  " \n" +
  " \(author)\n" +
  " \n" +
  ""

However, this creates a more complex expression for the type checker, and
there's still far more punctuation than ought to be necessary. If the most
important goal of Swift is making code readable, this kind of code falls
far short of that goal.



Proposed
solution

We propose that, when Swift is parsing a string literal, if it reaches the
end of the line without encountering an end quote, it should look at the
next line. If it sees a quote at the beginning (a "continuation quote"),
the string literal contains a newline and then continues on that line.
Otherwise, the string literal is unt

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

On 29.04.2016 1:31, Michael Peternell via swift-evolution wrote:

is it just me who would prefer a multiline string literal to not require
a \backslash before each "double quote"?


You are not alone ;-)
But, as I understand, the proposal does not even try to solve a problem of 
*as-is* text in sources, but is fighting against just \n"+ at the end of 
the string. That is what is proposed. I don't feel like it is a valuable 
improvement, but it is OK for me to have such feature in language.


IMO we need just 2 variants: current method where we can use all the 
escaped chars, interpolation, \n and closing quotes, and additionally 
should have a feature to paste text *as-is*, without escapes and 
interpolation. For example :


let xml = "\
|
|
|
|myAuthor
|myTitle \tutorial 1\(edition 2)
|
|
"

or

let xml = _"
"
"
"
"myAuthor
"myTitle \tutorial 1\(edition 2)
"
"




Did you ever really use multiline string literals before? I did, and
it's mostly for quick hacks where I wrote a script or tried something
out quickly. And maybe I needed to put an XML snippet into a unit test
case to see if my parser correctly parses or correctly rejects the
snippet. The current proposal doesn't help this use case in any way. I
cannot see which use case inspires multiline string literals which
require double quotes to be escaped... I wouldn't use them if they were
available. I'd become an Android developer instead ;)

-Michael


Am 28.04.2016 um 23:56 schrieb Brent Royal-Gordon via swift-evolution
:


Awesome.  Some specific suggestions below, but feel free to iterate
in a pull request if you prefer that.


I've adopted these suggestions in some form, though I also ended up
rewriting the explanation of why the feature was designed as it is and
fusing it with material from "Alternatives considered".

(Still not sure who I should list as a co-author. I'm currently
thinking John, Tyler, and maybe Chris? Who's supposed to go there?)

Multiline string literals

• Proposal: SE- • Author(s): Brent Royal-Gordon • Status: Second
Draft • Review manager: TBD Introduction

In Swift 2.2, the only means to insert a newline into a string literal
is the \n escape. String literals specified in this way are generally
ugly and unreadable. We propose a multiline string feature inspired by
English punctuation which is a straightforward extension of our
existing string literals.

This proposal is one step in a larger plan to improve how string
literals address various challenging use cases. It is not meant to
solve all problems with escaping, nor to serve all use cases involving
very long string literals. See the "Future directions for string
literals in general" section for a sketch of the problems we
ultimately want to address and some ideas of how we might do so.

Swift-evolution threads: multi-line string literals. (April),
multi-line string literals (December)

Draft Notes

• Removes the comment feature, which was felt to be an unnecessary
complication. This and the backslash feature have been listed as
future directions.

• Loosens the specification of diagnostics, suggesting instead of
requiring fix-its.

• Splits a "Rationale" section out of the "Proposed solution"
section.

• Adds extensive discussion of other features which wold combine with
this one.

• I've listed only myself as an author because I don't want to put
anyone else's name to a document they haven't seen, but there are
others who deserve to be listed (John Holdsworth at least). Let me
know if you think you should be included.

Motivation

As Swift begins to move into roles beyond app development, code which
needs to generate text becomes a more important use case. Consider,
for instance, generating even a small XML string:

let xml = "\n\n\t\n\t\t\(author)\n\t\n"
The string is practically unreadable, its structure drowned in escapes
and run-together lines; it looks like little more than line noise. We
can improve its readability somewhat by concatenating separate strings
for each line and using real tabs instead of \t escapes:

let xml = "\n" +


"\n" +


" \n" +


" \(author)\n" +


" \n" +


"" However, this creates a more complex expression for the
type checker, and there's still far more punctuation than ought to be
necessary. If the most important goal of Swift is making code
readable, this kind of code falls far short of that goal.

Proposed solution

We propose that, when Swift is parsing a string literal, if it reaches
the end of the line without encountering an end quote, it should look
at the next line. If it sees a quote at the beginning (a "continuation
quote"), the string literal contains a newline and then continues on
that line. Otherwise, the string literal is unterminated and
syntactically invalid.

Our sample above could thus be written as:

let xml = " " "  " \(author) "  ""

If the second or subsequent lines had not begun with a quotation mark,
or the trailing quotation mark after the tag had not

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

[Rod Brown via swift-evolution]

* What is your evaluation of the proposal?
+1 for the functionality on CollectionType
-1 for the functionality on SequenceType
 
* Is the problem being addressed significant enough to warrant a change to 
Swift?
It’s certainly a helpful addition and one I’ve got an analogous version of in 
my own projects. Considering this is a simply addition on CollectionType, I 
think there no reasons not to.

I’m concerned about this being added to SequenceType. The risks associated with 
iterating through a sequence where it may be destructive seem to great to me, 
especially when this can be limited to CollectionType instead.

* Does this proposal fit well with the feel and direction of Swift?
In general I find the proposal concept to be inline with Swift, for simplicity 
and ease of use. SequenceType usage however seems risky, due to the destructive 
iterator problem, and this seems against Swift’s safe direction.

* If you have you used other languages or libraries with a similar feature, how 
do you feel that this proposal compares to those?
I’ve used similar functionality added to NSArrays.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
A quick read, and was following the earlier discussion.

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

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

[Jose Cheyo Jimenez via swift-evolution]

>   * What is your evaluation of the proposal?

I think it is too limiting and I’d rather have find() be merged with current 
index() method.

// I believe these used to be called find() in swift 1.0
func index(of element: Self.Iterator.Element) -> Self.Index?
func index(@noescape where predicate: (Self.Iterator.Element) throws -> Bool) 
rethrows -> Self.Index?

I think it is really confusing to have an index() and a find() that do very 
similar things. 

I rather have an overloaded find() 

func find(indexOf element: Self.Iterator.Element) -> Self.Index?
func find(@noescape indexOf predicate: (Self.Iterator.Element) throws -> Bool) 
rethrows -> Self.Index?
func find(@noescape element predicate: (Self.Iterator.Element) throws -> Bool) 
rethrows -> Self.Iterator.Element?

// Return a tuple with the index and element
func find(@noescape predicate: (Self.Iterator.Element) throws -> Bool) rethrows 
-> (index:Self.Index, element:Self.Iterator.Element)?


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

yes,  I use filter for this but I believe find() and index() should be merged 
for it to be worth it. 

>   * Does this proposal fit well with the feel and direction of Swift?
yes but I believe index() should be renamed to find()

>   * If you have you 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?
read the proposal and suggested an extension of scope. 


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

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

Great and necessary. I particularly like that the combination of `iterate(1, 
apply: { $0 * 2 }).prefix(while: { $0 < 100_000 })` mimics the abilities of the 
old C-style for loop.

Bikeshedding time!

* * *

I really like the `reduce`/`reductions` pairing instead of `reduce`/`scan`; it 
does a really good job of explaining the relationship between the two 
functions. I also think the `startingWith` label may be a good idea, although 
if we do that, we might want to change the second label to `combiningWith`.

* * *

I believe that `prefix(while:)` and `dropFirst(while:)` would be most 
consistent with the current standard library, but frankly, I consider that an 
indictment of the current names.

`skip` is better than `drop`, but they are both pigs; one's just wearing 
lipstick. The whole area of APIs which grab subsets of Sequences or Collections 
could use some renaming. It is rife with both inconsistencies (`prefix(_:)` and 
`dropFirst(_:)` are inverses, but look unrelated) and names which appear to 
mutate but don't (all the `drop` APIs). These APIs are currently grandfathered 
in with the term-of-art rule, which I normally agree with, but I think the 
results here are so bad that we can't let them stand.

I would suggest that we systematically rename these APIs to achieve a 
consistent, non-verb-based pattern which the new APIs can slot into nicely:

first   // 
Currently first
prefix(_: Int)  // Currently 
prefix(_:)
prefix(while: Element -> Bool)  // Proposed as 
prefix(while:)

afterFirst() or afterFirst  // Currently 
dropFirst()
afterPrefix(_: Int) // Currently 
dropFirst(_:)
afterPrefix(while: Element -> Bool) // Proposed as 
drop(while:)

last// 
Currently last
suffix(_: Int)  // Currently 
suffix(_:)
suffix(while: Element -> Bool)  // Unproposed

beforeLast() or beforeLast  // Currently dropLast()
beforeSuffix(_: Int)// Currently 
dropLast(_:)
beforeSuffix(while: Element -> Bool)// Unproposed

before(to: Index)   // Currently 
prefix(upTo:)
before(through: Index)  // Currently 
prefix(through:)

after(to: Index)// 
Unproposed?
after(through: Index)   // suffix(from:)?

Several of these APIs are listed as "unproposed"; they are neither in the 
current standard library, nor in this proposal. I am not suggesting we add 
them, but simply showing how they would be named if they *were* provided.

If the core team wants to protect `dropFirst` and `dropLast` as terms of art, I 
think our best alternative is to make `first` and `last` nullary methods, and 
rename the `prefix` methods to `first` and `suffix` to `last`. It seems like 
the decision to make `first` and `last` properties was a little bit uncertain 
to begin with; I think the naming issues here tip the scales.

In any case, though, the core team might prefer to consider this relatively 
large renaming as a separate proposal. If so, as I said, I think 
`prefix(while:)` and `dropFirst(while:)` are the best matches for the current 
APIs.

* * *

I think `iterate` is the best basic approach to the name. My own prototypes 
used `induce` since the sequence was produced by induction from a starting 
value and transformation function, but this approach was too clever by half: 
people were confused by the name until it was explained, and then they thought 
it was clever but had trouble remembering it.

There is precedent in the current standard library for using an imperative verb 
to lazily construct a list: the `repeatElement(_:count:)` function. However, if 
we don't like that for this case, an alternative is to use the noun 
`iteration`. And if we're going with the noun, well, that suggests that what we 
really want to define is not a function, but a type:

struct Iteration: Sequence {
init(start startingValue: T, apply transformation: T -> T)
}

This reads fairly well in common uses:

for i in Iteration(start: 1, apply: { $0 * 2 }) { … }

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

Yes. As I mentioned before, the combination of `iterate` and `prefix(while:)` 
is particularly important.

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

Yes; these fill important holes in our ability to create and manipulate 
sequences.

>   * If you have yo

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Jordan Rose via swift-evolution]

[resending without quoting the proposal, because apparently that made Mail emit 
garbage today]


Hi, Erica. Sorry for not participating in the first round here. I’m…not so 
happy with this direction, for a number of reasons. (I apologize for the 
laundry list, but they’re not really related complaints.)

- ‘required’ already means something today: it means “this initializer must be 
present on all subclasses”. The reason it only applies to initializers is 
because all other members are always present on all subclasses.

(Counter-argument: using ‘required’ on an initializer could be seen as making 
an implicit protocol, just for that class hierarchy.)

- ‘override’ likewise already has a meaning; allowing ‘override’ to be 
satisfied by a protocol requirement means that it might miss an override 
intended for a superclass—or inadvertently become one when an SDK is updated.

(Counter-argument: that last can happen to protocols already.)

- This doesn’t cover cases where methods in one protocol extension satisfy 
requirements in another.

- This doesn’t cover retroactive modeling.

- I’m not sure what it means to "prefer an overridden implementation in 
preference in reverse hierarchical order: type extensions take precedence over 
type declarations over protocol extensions over protocol declarations (assuming 
protocol declarations eventually adopt default implementations)”. Protocol 
conformance is decided at compile time; there won’t ever be any members in type 
extensions that take precedent over a type declaration without causing a 
conflict. (That is, currently you are not allowed to define such a member.)

- A member in the type does not “override" a member in a protocol extension 
today, because such a call is not dynamically dispatched. Making protocol 
extension members dynamically dispatched is challenging at the least and would 
require an implementation plan in the proposal.

- Thank you for writing up all of the source compatibility cases! I think 
there’s no issue with binary compatibility, since IIUC the proposal doesn’t 
change how anything is implemented, and we think we know how to handle binary 
compatibility there. But I’d like to think about it a little more.

- The “A.foo(self)()” syntax is clever, but it doesn’t work correctly for 
mutating methods (because you can’t curry an inout). On the other hand, JoeG 
already brought up the idea of making ‘self’ the first argument of the implicit 
static member. It still doesn’t solve the problem of picking a protocol 
extension, but that’s not new. (This isn’t a complaint, I guess, just a note.)


I’m not sure I have a meaningful summary or conclusion, but I’d be hesitant to 
do all of this without these concerns being addressed.

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Jordan Rose via swift-evolution]

Hi, Erica. Sorry for not participating in the first round here. I’m…not so 
happy with this direction, for a number of reasons. (I apologize for the 
laundry list, but they’re not really related complaints.)

- ‘required’ already means something today: it means “this initializer must be 
present on all subclasses”. The reason it only applies to initializers is 
because all other members are always present on all subclasses.

(Counter-argument: using ‘required’ on an initializer could be seen as making 
an implicit protocol, just for that class hierarchy.)

- ‘override’ likewise already has a meaning; allowing ‘override’ to be 
satisfied by a protocol requirement means that it might miss an override 
intended for a superclass—or inadvertently become one when an SDK is updated.

(Counter-argument: that last can happen to protocols already.)

- This doesn’t cover cases where methods in one protocol extension satisfy 
requirements in another.

- This doesn’t cover retroactive modeling.

- I’m not sure what it means to "prefer an overridden implementation in 
preference in reverse hierarchical order: type extensions take precedence over 
type declarations over protocol extensions over protocol declarations (assuming 
protocol declarations eventually adopt default implementations)”. Protocol 
conformance is decided at compile time; there won’t ever be any members in type 
extensions that take precedent over a type declaration without causing a 
conflict. (That is, currently you are not allowed to define such a member.)

- A member in the type does not “override" a member in a protocol extension 
today, because such a call is not dynamically dispatched. Making protocol 
extension members dynamically dispatched is challenging at the least and would 
require an implementation plan in the proposal.

- Thank you for writing up all of the source compatibility cases! I think 
there’s no issue with binary compatibility, since IIUC the proposal doesn’t 
change how anything is implemented, and we think we know how to handle binary 
compatibility there. But I’d like to think about it a little more.

- The “A.foo(self)()” syntax is clever, but it doesn’t work correctly for 
mutating methods (because you can’t curry an inout). On the other hand, JoeG 
already brought up the idea of making ‘self’ the first argument of the implicit 
static member. It still doesn’t solve the problem of picking a protocol 
extension, but that’s not new. (This isn’t a complaint, I guess, just a note.)


I’m not sure I have a meaningful summary or conclusion, but I’d be hesitant to 
do all of this without these concerns being addressed.

Jordan



> On Apr 28, 2016, at 09:53, Erica Sadun  wrote:
> 
> Draft. Criticism and suggestions both welcome. -- E
> 
> Requiring Proactive Overrides for Default Protocol Implementations
> 
> Proposal: tbd
> Author(s): Erica Sadun 
> Status: tbd
> Review manager: tbd
>  
> Introduction
> 
> This proposal enhances protocol implementation safety. It incorporates two 
> keywords that cooperate with compiler checks to limit "near miss" 
> implementation errors and accidental member overrides.
> 
> This proposal was discussed on the Swift Evolution list in the [Pitch] 
> Requiring proactive overrides for default protocol implementations. 
>  thread
> 
>  
> Motivation
> 
> The proposal introduces a mandatory required keyword that marks members as 
> fulfiling protocol requirements. This expansion reduces the risk of near-miss 
> implementations (for example, adding thud(x: Double) when thud(x: Float)is 
> required), provides in-line documentation of why the member has been 
> included, thereby enhancing the code-level documentation at the 
> implementation point, and supports compile-time checks for protocol 
> conformance.
> 
> This proposal extends the override keyword to protocol conformance. The Swift 
> Programming Language describes the way subclass methods must override 
> implementations established in superclasses. Methods on a subclass that 
> override the superclass’s implementation are marked with 
> *override*—overriding a method by accident, without override, is detected by 
> the compiler as an error. The compiler also detects methods with override 
> that don’t actually override any method in the superclass.
> 
> Adding an override requirement expands this cautious approach to protocols. 
> Developers must override implementations inherited from protocol extensions 
> with the override keyword. And the compiler will flag uses of override where 
> member implementations do not, in fact, override an existing implementation. 
> The keyword prevents accidental overrides, where a sensible member name 
> conflicts with signatures established in the protocol conformance and

Re: [swift-evolution] Localization support for string interpolation

[Brent Royal-Gordon via swift-evolution]

> – Inserting a number into a sentence often requires adjusting other parts of 
> the sentence (nouns, verbs, articles) to the number. And while English has 
> only singular and plural, other languages distinguish more cases – up to six 
> for Arabic.
> 
> – Inserting a name or noun into a sentence often requires adjusting other 
> parts of the sentence to the gender of the person or noun. While in English 
> gender usually is only reflected in pronouns, its impact is pervasive in some 
> other languages.
> 
> – Formats for numbers and dates should be specified at a high enough level 
> that they can be automatically translated by internationalization libraries. 
> For example, don’t specify the order of year, month, day and the characters 
> to be used around them; specify just whether you want to have a long or a 
> short form and which components, and let an internationalization library 
> handle the rest.

This is all true, but it's also all handled by Foundation on Apple platforms 
and hopefully by Corelibs Foundation elsewhere. We ought to be able to hook 
into this existing machinery.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 9:53 PM, Erica Sadun  wrote:

>
> On Apr 28, 2016, at 8:46 PM, Xiaodi Wu  wrote:
> Let's return to the toy example. Suppose I license the following code from
> a third party. I am allowed to incorporate it unmodified into my project:
>
> ```
> // I cannot touch any of the following code
> struct A {
> func frobnicate() { print("A") }
> }
> struct B {
> func frobnicate() { print("B") }
> }
> struct C { }
> ```
>
> The code above has three types that conform to no protocols. Nothing would
> change on adoption of your proposal. As licensed to me from the third
> party, there are no protocols for it to conform to.
>
> Now, in a separate file, as part of my own code, I want to conform these
> three types to a protocol of my own design, Frobnicatable, and supply a
> default `frobnicate()`:
>
> ```
> protocol Frobnicatable {
> func frobnicate()
> }
> extension Frobnicatable {
> func frobnicate() { print("Default") }
> }
> extension A: Frobnicatable { }
> extension B: Frobnicatable { }
> extension C: Frobnicatable { }
>
> let a = A()
> a.frobnicate() // "A"
> let c = C()
> c.frobnicate() // "Default"
> ```
>
> It seems like there is nothing I can do to make this work upon
> implementation of your proposal.
>
>
> Is this your desired behavior or is this the behavior you expect?
> By implementing a default, you inherit that behavior in all three, because
> *you* added it.
> I expect the compiler to complain at your default because you did not mark
> it as required.
>
> If you want to use the inherent frobnicate and not the default one that
> you just added,
> you will need to do something like:
>
> extension A: Frobnicate {
>override required frobnicate = A.frobnicate
> }
>

What's shown in comments is how it *currently* behaves. That can be
verified in a playground (or the IBM sandbox online). I'm not sure I have a
strong opinion yet on how it *should* behave, although what I'm asking is
whether I *can* make it behave in the same way as it does currently.

If what you show above as a solution is part of your proposal, then that
should be sufficient to support my use case. Please do document it in the
text though. IMO, this is key. It's not enough to say, just modify the
original code, or just use a compiled module, or hope that the code is
written in something other than Swift 3.

I still have reservations about requiring both `override` and `required`,
which current Swift syntax never does. I understand what you're getting at,
but I'm not sure making the distinction between `override` and `override
required` will provide additional safety in practice. My reasoning:
`override` implies that there's an implementation provided somewhere, and
`required` implies there's a protocol requirement somewhere, but either one
alone is sufficient to tell the compiler "yes, I intend to write a function
with the same name as something else--please tell me if I failed to do so."
What would be lost (safety-wise) if we followed Swift precedent, and
`override required` got simplified to `override`?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Apr 28, 2016, at 8:46 PM, Xiaodi Wu  wrote:
> Let's return to the toy example. Suppose I license the following code from a 
> third party. I am allowed to incorporate it unmodified into my project:
> 
> ```
> // I cannot touch any of the following code
> struct A {
> func frobnicate() { print("A") }
> }
> struct B {
> func frobnicate() { print("B") }
> }
> struct C { }
> ```
> 
> The code above has three types that conform to no protocols. Nothing would 
> change on adoption of your proposal. As licensed to me from the third party, 
> there are no protocols for it to conform to.
> 
> Now, in a separate file, as part of my own code, I want to conform these 
> three types to a protocol of my own design, Frobnicatable, and supply a 
> default `frobnicate()`:
> 
> ```
> protocol Frobnicatable {
> func frobnicate()
> }
> extension Frobnicatable {
> func frobnicate() { print("Default") }
> }
> extension A: Frobnicatable { }
> extension B: Frobnicatable { }
> extension C: Frobnicatable { }
> 
> let a = A()
> a.frobnicate() // "A"
> let c = C()
> c.frobnicate() // "Default"
> ```
> 
> It seems like there is nothing I can do to make this work upon implementation 
> of your proposal.

Is this your desired behavior or is this the behavior you expect?
By implementing a default, you inherit that behavior in all three, because 
*you* added it.
I expect the compiler to complain at your default because you did not mark it 
as required.

If you want to use the inherent frobnicate and not the default one that you 
just added,
you will need to do something like:

extension A: Frobnicate {
   override required frobnicate = A.frobnicate
}

-- E

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

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

[David Waite via swift-evolution]

> The review of "SE-0032: Add find method to SequenceType" begins now and runs 
> through May 3. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0032-sequencetype-find.md


> * What is your evaluation of the proposal?
-0 for naming reasons

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
Sure
> 
> * Does this proposal fit well with the feel and direction of Swift?
Not entirely. Because Sequence operations are based on the iterator, and the 
iterator is not guaranteed to be either non-destructive/resetting or finite, a 
find method could lead to subtle bugs.

I would prefer either another name such as skipUntil, or that find exist on 
Collection which does have the guarantee of being non-destructive and 
resettable on iteration.

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

skipUntil is the closest I see in reactive programming sources, which process 
events as a stream rather than as a resettable cursor into a data structure.

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

A quick reading.

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

Re: [swift-evolution] Localization support for string interpolation

[Norbert Lindenberg via swift-evolution]

> On Apr 26, 2016, at 16:16 , Dave Abrahams via swift-evolution 
>  wrote:
> 
> Also, frankly I think printf syntax is arcane and readable only to a
> small fraction of developers.  Take a complete read through the man page
> sometime if you really want your mind blown!
> 
> If you're going to take a string interpolation approach, we can instead
> know *exactly* what formatting options apply to “foo,” express them
> readably, and check them at compile time.
> 
> The problem is that localization may really be incompatible with
> Swift-style compile-time-checked string interpolation with embedded
> formatting, because of:
> 
> 1. The need to look up localized strings in tables for a given language,
>   making them basically dynamic as far as the compiler is concerned.
> 
> 2. The need for localizers (i.e. not the application programmer) to
>   tune both the string content and how the arguments are formatted.

Very true. Separating localizable strings from source code is critical to 
making the localization process manageable, and the syntax used in localizable 
strings must be easy to understand for translators, who are hardly ever 
engineers, or supported by the tools that translators use.

Localization of messages also has some requirements that haven’t been discussed 
here yet:

– Inserting a number into a sentence often requires adjusting other parts of 
the sentence (nouns, verbs, articles) to the number. And while English has only 
singular and plural, other languages distinguish more cases – up to six for 
Arabic.

– Inserting a name or noun into a sentence often requires adjusting other parts 
of the sentence to the gender of the person or noun. While in English gender 
usually is only reflected in pronouns, its impact is pervasive in some other 
languages.

– Formats for numbers and dates should be specified at a high enough level that 
they can be automatically translated by internationalization libraries. For 
example, don’t specify the order of year, month, day and the characters to be 
used around them; specify just whether you want to have a long or a short form 
and which components, and let an internationalization library handle the rest.

One well supported and commonly used library handling this is ICU with its 
MessageFormat class:
http://userguide.icu-project.org/formatparse/messages
http://icu-project.org/apiref/icu4c/classMessageFormat.html#details

If there is dedicated support for localizable messages in Swift, it should be 
at least as good as MessageFormat – and translators should have at least as 
strong a say in what’s good as software engineers.

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 9:40 PM, Erica Sadun  wrote:
>
> Without actually trying to understand the details of your math stuff:
>
> * If you add a required member in a declaration or extension that declares
> conformance, it is 'required'.
> * If it is already defaulted, it is `override required`.
> * If it is already defaulted but not required, it is `override`
> * If someone else implements the stuff, you still have to pull it in
> somehow, but if you do so by conforming to another protocol with an
> extension, it's not your business, so you don't use any keywords.
>
> You use keywords only for stuff that you specifically write, that
> clarifies the context in which you are writing it. If you do not own a
> protocol, an extension, or an implementation, you do not change or markup
> the protocol, extension, or implementation. You're just offering the
> compiler hints that your otherwise questionable decisions are fully
> intentional: when overriding an existing implementation and when conforming
> by supplying a required member.
>
> -- E, who still probably missed your point and again apologizes
>
>
> * If this is not Swift code it is not affected.
> * If it is Swift code, either use #if swift(>= blah) workarounds or
> propose that SwiftPM support earlier Swift compilation rules.
> * If this is adopted and the code is in Swift 3, it would already have
> compliances and you do not need to add anything
>
> Under what scenario could you possibly use 3rd party Swift 3 code
> (assuming adoption) that would require annotation/changing?
>

Let's return to the toy example. Suppose I license the following code from
a third party. I am allowed to incorporate it unmodified into my project:

```
// I cannot touch any of the following code
struct A {
func frobnicate() { print("A") }
}
struct B {
func frobnicate() { print("B") }
}
struct C { }
```

The code above has three types that conform to no protocols. Nothing would
change on adoption of your proposal. As licensed to me from the third
party, there are no protocols for it to conform to.

Now, in a separate file, as part of my own code, I want to conform these
three types to a protocol of my own design, Frobnicatable, and supply a
default `frobnicate()`:

```
protocol Frobnicatable {
func frobnicate()
}
extension Frobnicatable {
func frobnicate() { print("Default") }
}
extension A: Frobnicatable { }
extension B: Frobnicatable { }
extension C: Frobnicatable { }

let a = A()
a.frobnicate() // "A"
let c = C()
c.frobnicate() // "Default"
```

It seems like there is nothing I can do to make this work upon
implementation of your proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Apr 28, 2016, at 8:25 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> On Apr 28, 2016, at 8:11 PM, Xiaodi Wu  > wrote:
>> 
>> Sorry, stripped out a little too much, I guess. Let me expand a little:
>> 
>> In this example, `PortedTransform` has, by virtue of how it works, an upper 
>> bound and lower bound for valid input (among other interesting methods and 
>> properties). Exceed those bounds for your input and `PortedTransform` 
>> regurgitates garbage but does not throw any kind of error. Obviously, linear 
>> transform does not care about such silly things because it can transform 
>> essentially any FP input value, while the log transform simply traps when it 
>> encounters a negative value (which, as a precondition, it should never 
>> encounter).
>> 
>> BLAS is an accelerated linear algebra library; Apple has implemented a very 
>> nicely optimized one as part of its Accelerate framework. I use BLAS to sum, 
>> for example, two arrays of floating point values--it's very, very highly 
>> optimized. In that situation, there's no trapping when a single value is out 
>> of bounds (I get NaNs instead), and thus I must determine bounds in order to 
>> anticipate when the output will be garbage or NaN. (There are, as part of 
>> the Accelerate framework, accelerated functions to clamp entire arrays to 
>> given bounds with maximal efficiency).
>> 
>> For accelerated scaling and unscaling, then, it is essentially always 
>> necessary to compute upper and lower bounds even when that's unnecessary for 
>> non-accelerated scaling and unscaling, which operates on one value at a 
>> time. For that reason, `AcceleratedTransform` requires methods that compute 
>> upper and lower bounds, and provides a default implementation of accelerated 
>> clamping that calls those bound-computing methods and then uses the results 
>> as parameters when calling functions in Accelerate.framework. Methods for 
>> the computation of bounds already exist in `PortedTransform` but not in my 
>> own transforms. With your proposal, how would I retroactively model this 
>> requirement without touching code for `PortedTransform` and without 
>> compiling this one class into its own library? I'd like to be able to take 
>> advantage of the maximum possible compiler optimization, and optimizing 
>> across module boundaries is (as far as I understand) a little dicier. 
>> (Moreover, for MyLinTransform, I override the clamping method to return the 
>> input without calling out to any framework functions because I know a priori 
>> that the bounds are -infinity and infinity. I think that override will still 
>> be possible under your proposal, though.)
> 
> Without actually trying to understand the details of your math stuff:
> 
> * If you add a required member in a declaration or extension that declares 
> conformance, it is 'required'. 
> * If it is already defaulted, it is `override required`. 
> * If it is already defaulted but not required, it is `override`
> * If someone else implements the stuff, you still have to pull it in somehow, 
> but if you do so by conforming to another protocol with an extension, it's 
> not your business, so you don't use any keywords.
> 
> You use keywords only for stuff that you specifically write, that clarifies 
> the context in which you are writing it. If you do not own a protocol, an 
> extension, or an implementation, you do not change or markup the protocol, 
> extension, or implementation. You're just offering the compiler hints that 
> your otherwise questionable decisions are fully intentional: when overriding 
> an existing implementation and when conforming by supplying a required member.
> 
> -- E, who still probably missed your point and again apologizes

* If this is not Swift code it is not affected.
* If it is Swift code, either use #if swift(>= blah) workarounds or propose 
that SwiftPM support earlier Swift compilation rules.
* If this is adopted and the code is in Swift 3, it would already have 
compliances and you do not need to add anything

Under what scenario could you possibly use 3rd party Swift 3 code (assuming 
adoption) that would require annotation/changing?

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 9:25 PM, Erica Sadun  wrote:

> On Apr 28, 2016, at 8:11 PM, Xiaodi Wu  wrote:
>
>
> Sorry, stripped out a little too much, I guess. Let me expand a little:
>
> In this example, `PortedTransform` has, by virtue of how it works, an
> upper bound and lower bound for valid input (among other interesting
> methods and properties). Exceed those bounds for your input and
> `PortedTransform` regurgitates garbage but does not throw any kind of
> error. Obviously, linear transform does not care about such silly things
> because it can transform essentially any FP input value, while the log
> transform simply traps when it encounters a negative value (which, as a
> precondition, it should never encounter).
>
> BLAS is an accelerated linear algebra library; Apple has implemented a
> very nicely optimized one as part of its Accelerate framework. I use BLAS
> to sum, for example, two arrays of floating point values--it's very, very
> highly optimized. In that situation, there's no trapping when a single
> value is out of bounds (I get NaNs instead), and thus I must determine
> bounds in order to anticipate when the output will be garbage or NaN.
> (There are, as part of the Accelerate framework, accelerated functions to
> clamp entire arrays to given bounds with maximal efficiency).
>
> For accelerated scaling and unscaling, then, it is essentially always
> necessary to compute upper and lower bounds even when that's unnecessary
> for non-accelerated scaling and unscaling, which operates on one value at a
> time. For that reason, `AcceleratedTransform` requires methods that compute
> upper and lower bounds, and provides a default implementation of
> accelerated clamping that calls those bound-computing methods and then uses
> the results as parameters when calling functions in Accelerate.framework.
> Methods for the computation of bounds already exist in `PortedTransform`
> but not in my own transforms. With your proposal, how would I retroactively
> model this requirement without touching code for `PortedTransform` and
> without compiling this one class into its own library? I'd like to be able
> to take advantage of the maximum possible compiler optimization, and
> optimizing across module boundaries is (as far as I understand) a little
> dicier. (Moreover, for MyLinTransform, I override the clamping method to
> return the input without calling out to any framework functions because I
> know a priori that the bounds are -infinity and infinity. I think that
> override will still be possible under your proposal, though.)
>
>
> Without actually trying to understand the details of your math stuff:
>
> * If you add a required member in a declaration or extension that declares
> conformance, it is 'required'.
> * If it is already defaulted, it is `override required`.
> * If it is already defaulted but not required, it is `override`
> * If someone else implements the stuff, you still have to pull it in
> somehow, but if you do so by conforming to another protocol with an
> extension, it's not your business, so you don't use any keywords.
>
> You use keywords only for stuff that you specifically write, that
> clarifies the context in which you are writing it. If you do not own a
> protocol, an extension, or an implementation, you do not change or markup
> the protocol, extension, or implementation. You're just offering the
> compiler hints that your otherwise questionable decisions are fully
> intentional: when overriding an existing implementation and when conforming
> by supplying a required member.
>
> -- E, who still probably missed your point and again apologizes
>

I do not own the code, I do not write the code, but I am compiling it. The
compiler does not know I do not own the code, and it will try to force me
to edit it. Which it is physically possible for me to do, but perhaps not
legally so, or perhaps it is not best practice because it's third-party
code and I cannot upstream that change (nor would it make sense to do so
without also upstreaming the actual extensions I am writing, which are
out-of-scope for the upstream project).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

My bad for such a convoluted example. All of this is trying to say
something rather simple:

I'm sure almost all of you who've worked with C++ have used Boost
header-only libraries. Many of them are really nice.

There are reasons why third-party Swift code might be distributed by one
person and incorporated by another person in source form, a la Boost
header-only libraries. One of these reasons would be that some compiler
optimizations are not possible across module boundaries. With the
implementation of your proposal, such third-party code could not be both
incorporated as source (as opposed to a compiled module) and extended in
certain ways without modifying the code itself. To me, that's a loss.


On Thu, Apr 28, 2016 at 9:11 PM, Xiaodi Wu  wrote:

> On Thu, Apr 28, 2016 at 8:32 PM, Erica Sadun  wrote:
>
>>
>> On Apr 28, 2016, at 6:20 PM, Xiaodi Wu  wrote:
>>
>> On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun 
>> wrote:
>>
>>> Can you give me a specific example of where this approach fails for you?
>>>
>>> -- E
>>>
>>
>>
>> Sure, I'll describe one (renaming some things for clarity and stripping
>> out the meat of the code, because it's not relevant and because it's not
>> elegant)--
>>
>> In one file, I have:
>>
>> ```
>> class PortedTransfom {
>> // this class was ported from C++
>> // it transforms input FP values to output values in a complicated way
>> // it's a standalone entity and the algorithm is even under patent
>> // (not owned by me, though it's legal for me to use it for my purposes)
>> // for this reason, this ported code lives in its own file
>> }
>> ```
>>
>> In another file, I have:
>>
>> ```
>> class MyAsinhTransform {
>> // this class was written by me
>> // nothing earth-shattering here
>> }
>>
>> class MyLogTransform {
>> // also written by me
>> }
>>
>> class MyLinearTransform {
>> // also written by me
>> }
>> ```
>>
>> Transforming values one-at-a-time isn't fast enough, so in another file,
>> I have:
>>
>> ```
>> import Accelerate
>>
>> protocol AcceleratedTransform {
>>   func scale(_: [Double]) -> [Double]
>>   func unscale(_: [Double]) -> [Double]
>> // other functions here
>> // some are already implemented in PortedTransform, though
>> }
>> extension AcceleratedTransform {
>> // default implementations for some functions
>> // but not `scale(_:)` and `unscale(_:)`, obviously
>> }
>>
>> extension MyAsinhTransform : AcceleratedTransform {
>> // use BLAS to implement scale(_:) and unscale(_:)
>> // and override some default implementations
>> }
>>
>> extension MyLogTransform : AcceleratedTransform {
>> // use BLAS to implement scale(_:) and unscale(_:)
>> // and override some default implementations
>> }
>>
>> extension  MyLinearTransform : AcceleratedTransform {
>> // use BLAS to implement scale(_:) and unscale(_:)
>> // and override some default implementations
>> }
>>
>> extension PortedTransform : AcceleratedTransform {
>> // use BLAS to implement scale(_:) and unscale(_:)
>> }
>> ```
>>
>>
>> I think I'm missing something here in terms of a question.  Your imported
>> stuff is your imported stuff.
>> Your extension implements "required" elements but not scale or unscale.
>>
>> If you extend MyAsinhTransform, you do required but not override for
>> scale/unscale. You do required override for anything you replace from
>> AcceleratedTransform.
>> What is BLAS? And what are you specifically asking about?
>>
>> -- E, apologizing for not understanding
>>
>>
> Sorry, stripped out a little too much, I guess. Let me expand a little:
>
> In this example, `PortedTransform` has, by virtue of how it works, an
> upper bound and lower bound for valid input (among other interesting
> methods and properties). Exceed those bounds for your input and
> `PortedTransform` regurgitates garbage but does not throw any kind of
> error. Obviously, linear transform does not care about such silly things
> because it can transform essentially any FP input value, while the log
> transform simply traps when it encounters a negative value (which, as a
> precondition, it should never encounter).
>
> BLAS is an accelerated linear algebra library; Apple has implemented a
> very nicely optimized one as part of its Accelerate framework. I use BLAS
> to sum, for example, two arrays of floating point values--it's very, very
> highly optimized. In that situation, there's no trapping when a single
> value is out of bounds (I get NaNs instead), and thus I must determine
> bounds in order to anticipate when the output will be garbage or NaN.
> (There are, as part of the Accelerate framework, accelerated functions to
> clamp entire arrays to given bounds with maximal efficiency).
>
> For accelerated scaling and unscaling, then, it is essentially always
> necessary to compute upper and lower bounds even when that's unnecessary
> for non-accelerated scaling and unscaling, which operates on one value at a
> time. For that reason, `AcceleratedTransform` requires methods that compute
> upper and lower bounds, and provides 

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Brad Hilton via swift-evolution]

You're right and since you can't nest any kind of type in a generic type
right, that wouldn't work even with this proposal. However, in the generics
manifesto they did say that they intend to remove that restriction. If they
do lift the restriction, they may have to leave an exception in place for
protocols.

On Thu, Apr 28, 2016 at 5:27 PM, Douglas Gregor  wrote:

>
> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Type nesting allows some convenient and straightforward semantics that we
> see inside the Swift standard library such as views on String like
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
> cannot be nested in a type and gives a non-obvious error that the
> “Declaration is only valid at file scope.” Just as other nested types allow
> proper contextual scoping, a nested protocol could make a lot sense for a
> number of patterns. For example, there are many “Delegate” protocols
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
> before and after type nesting:
>
> // Without type nesting
>
> protocol MyControllerDelegate : class {
>
> }
>
> class MyController {
>
> weak var delegate: MyControllerDelegate?
>
> }
>
> // With type nesting
>
> class MyController {
>
> weak var delegate: Delegate?
>
> protocol Delegate : class {
>
> }
>
> }
>
> Though the change is mostly semantics, it does allow an explicit
> association between My Controller and the Delegate instead of only a named
> association. It also cleans up the module name space like other nested
> types and makes associated protocols more discoverable in my opinion.
>
> I’d love to hear everyone’s thoughts.
>
>
> Note that this cannot work when any enclosing type is generic, e.g.,
>
> class MyController {
>   protocol Delegate {
> // I’ve just created a parameterized protocol!
>   }
> }
>
>
> Otherwise, I don’t see any issues with the proposal, and I like that it
> eliminates a large number of top-level names.
>
> - Doug
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

On Apr 28, 2016, at 8:11 PM, Xiaodi Wu  wrote:
> 
> Sorry, stripped out a little too much, I guess. Let me expand a little:
> 
> In this example, `PortedTransform` has, by virtue of how it works, an upper 
> bound and lower bound for valid input (among other interesting methods and 
> properties). Exceed those bounds for your input and `PortedTransform` 
> regurgitates garbage but does not throw any kind of error. Obviously, linear 
> transform does not care about such silly things because it can transform 
> essentially any FP input value, while the log transform simply traps when it 
> encounters a negative value (which, as a precondition, it should never 
> encounter).
> 
> BLAS is an accelerated linear algebra library; Apple has implemented a very 
> nicely optimized one as part of its Accelerate framework. I use BLAS to sum, 
> for example, two arrays of floating point values--it's very, very highly 
> optimized. In that situation, there's no trapping when a single value is out 
> of bounds (I get NaNs instead), and thus I must determine bounds in order to 
> anticipate when the output will be garbage or NaN. (There are, as part of the 
> Accelerate framework, accelerated functions to clamp entire arrays to given 
> bounds with maximal efficiency).
> 
> For accelerated scaling and unscaling, then, it is essentially always 
> necessary to compute upper and lower bounds even when that's unnecessary for 
> non-accelerated scaling and unscaling, which operates on one value at a time. 
> For that reason, `AcceleratedTransform` requires methods that compute upper 
> and lower bounds, and provides a default implementation of accelerated 
> clamping that calls those bound-computing methods and then uses the results 
> as parameters when calling functions in Accelerate.framework. Methods for the 
> computation of bounds already exist in `PortedTransform` but not in my own 
> transforms. With your proposal, how would I retroactively model this 
> requirement without touching code for `PortedTransform` and without compiling 
> this one class into its own library? I'd like to be able to take advantage of 
> the maximum possible compiler optimization, and optimizing across module 
> boundaries is (as far as I understand) a little dicier. (Moreover, for 
> MyLinTransform, I override the clamping method to return the input without 
> calling out to any framework functions because I know a priori that the 
> bounds are -infinity and infinity. I think that override will still be 
> possible under your proposal, though.)

Without actually trying to understand the details of your math stuff:

* If you add a required member in a declaration or extension that declares 
conformance, it is 'required'. 
* If it is already defaulted, it is `override required`. 
* If it is already defaulted but not required, it is `override`
* If someone else implements the stuff, you still have to pull it in somehow, 
but if you do so by conforming to another protocol with an extension, it's not 
your business, so you don't use any keywords.

You use keywords only for stuff that you specifically write, that clarifies the 
context in which you are writing it. If you do not own a protocol, an 
extension, or an implementation, you do not change or markup the protocol, 
extension, or implementation. You're just offering the compiler hints that your 
otherwise questionable decisions are fully intentional: when overriding an 
existing implementation and when conforming by supplying a required member.

-- E, who still probably missed your point and again apologizes


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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Kurt Werle via swift-evolution]

As a ruby programmer, I have to admit that I've tried to do this in Swift
several times before remembering again that it isn't possible.
+1

On Thu, Apr 28, 2016 at 3:44 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 very handy to associate types together
>
>
> On Friday, 29 April 2016, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think that would be a good feature.
>>
>> > Am 28.04.2016 um 19:15 schrieb Brad Hilton via swift-evolution <
>> swift-evolution@swift.org>:
>> >
>> > Type nesting allows some convenient and straightforward semantics that
>> we see inside the Swift standard library such as views on String like
>> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
>> cannot be nested in a type and gives a non-obvious error that the
>> “Declaration is only valid at file scope.” Just as other nested types allow
>> proper contextual scoping, a nested protocol could make a lot sense for a
>> number of patterns. For example, there are many “Delegate” protocols
>> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
>> before and after type nesting:
>> >
>> > // Without type nesting
>> >
>> > protocol MyControllerDelegate : class {
>> >
>> > }
>> >
>> > class MyController {
>> >
>> > weak var delegate: MyControllerDelegate?
>> >
>> > }
>> >
>> > // With type nesting
>> >
>> > class MyController {
>> >
>> > weak var delegate: Delegate?
>> >
>> > protocol Delegate : class {
>> >
>> > }
>> >
>> > }
>> >
>> > Though the change is mostly semantics, it does allow an explicit
>> association between My Controller and the Delegate instead of only a named
>> association. It also cleans up the module name space like other nested
>> types and makes associated protocols more discoverable in my opinion.
>> >
>> > I’d love to hear everyone’s thoughts.
>> >
>> > Brad Hilton
>> > ___
>> > 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
>>
>
>
> --
> -- Howard.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 8:32 PM, Erica Sadun  wrote:

>
> On Apr 28, 2016, at 6:20 PM, Xiaodi Wu  wrote:
>
> On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun  wrote:
>
>> Can you give me a specific example of where this approach fails for you?
>>
>> -- E
>>
>
>
> Sure, I'll describe one (renaming some things for clarity and stripping
> out the meat of the code, because it's not relevant and because it's not
> elegant)--
>
> In one file, I have:
>
> ```
> class PortedTransfom {
> // this class was ported from C++
> // it transforms input FP values to output values in a complicated way
> // it's a standalone entity and the algorithm is even under patent
> // (not owned by me, though it's legal for me to use it for my purposes)
> // for this reason, this ported code lives in its own file
> }
> ```
>
> In another file, I have:
>
> ```
> class MyAsinhTransform {
> // this class was written by me
> // nothing earth-shattering here
> }
>
> class MyLogTransform {
> // also written by me
> }
>
> class MyLinearTransform {
> // also written by me
> }
> ```
>
> Transforming values one-at-a-time isn't fast enough, so in another file, I
> have:
>
> ```
> import Accelerate
>
> protocol AcceleratedTransform {
>   func scale(_: [Double]) -> [Double]
>   func unscale(_: [Double]) -> [Double]
> // other functions here
> // some are already implemented in PortedTransform, though
> }
> extension AcceleratedTransform {
> // default implementations for some functions
> // but not `scale(_:)` and `unscale(_:)`, obviously
> }
>
> extension MyAsinhTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
>
> extension MyLogTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
>
> extension  MyLinearTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
>
> extension PortedTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> }
> ```
>
>
> I think I'm missing something here in terms of a question.  Your imported
> stuff is your imported stuff.
> Your extension implements "required" elements but not scale or unscale.
>
> If you extend MyAsinhTransform, you do required but not override for
> scale/unscale. You do required override for anything you replace from
> AcceleratedTransform.
> What is BLAS? And what are you specifically asking about?
>
> -- E, apologizing for not understanding
>
>
Sorry, stripped out a little too much, I guess. Let me expand a little:

In this example, `PortedTransform` has, by virtue of how it works, an upper
bound and lower bound for valid input (among other interesting methods and
properties). Exceed those bounds for your input and `PortedTransform`
regurgitates garbage but does not throw any kind of error. Obviously,
linear transform does not care about such silly things because it can
transform essentially any FP input value, while the log transform simply
traps when it encounters a negative value (which, as a precondition, it
should never encounter).

BLAS is an accelerated linear algebra library; Apple has implemented a very
nicely optimized one as part of its Accelerate framework. I use BLAS to
sum, for example, two arrays of floating point values--it's very, very
highly optimized. In that situation, there's no trapping when a single
value is out of bounds (I get NaNs instead), and thus I must determine
bounds in order to anticipate when the output will be garbage or NaN.
(There are, as part of the Accelerate framework, accelerated functions to
clamp entire arrays to given bounds with maximal efficiency).

For accelerated scaling and unscaling, then, it is essentially always
necessary to compute upper and lower bounds even when that's unnecessary
for non-accelerated scaling and unscaling, which operates on one value at a
time. For that reason, `AcceleratedTransform` requires methods that compute
upper and lower bounds, and provides a default implementation of
accelerated clamping that calls those bound-computing methods and then uses
the results as parameters when calling functions in Accelerate.framework.
Methods for the computation of bounds already exist in `PortedTransform`
but not in my own transforms. With your proposal, how would I retroactively
model this requirement without touching code for `PortedTransform` and
without compiling this one class into its own library? I'd like to be able
to take advantage of the maximum possible compiler optimization, and
optimizing across module boundaries is (as far as I understand) a little
dicier. (Moreover, for MyLinTransform, I override the clamping method to
return the input without calling out to any framework functions because I
know a priori that the bounds are -infinity and infinity. I think that
override will still be possible under your proposal, though.)
___

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Dany St-Amant via swift-evolution]

> Le 28 avr. 2016 à 03:34, Pyry Jahkola via swift-evolution 
>  a écrit :
> 
> Good that you brought the topic of "fluent" interfaces up. I don't see any 
> problem with explicit value type mutation and method chaining because fluent 
> interfaces are constrained to reference types by the language. Details below:
> 
>> On 28 Apr 2016, at 03:44, Tyler Cloutier  wrote:
>> 
>> How would this chain if I wanted to do something like:
>> 
>> let median = foo.calculateBigHugeArray().sort().medianValue()
>> 
>> and I want the sort to be done in place.
> 
> I think I can guess what you wanted the above to mean but, mind you, the 
> in-place sort returns `()` so you wouldn't chain its result like that. On the 
> other hand, the above code already works using the non-mutating `.sort()` (to 
> be known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler 
> probably optimises the copy away using copy-on-write anyway.
> 
>> Or will this type of thing just be disallowed in favor of.
>> 
>> let array = foo.calculateBigHugeArray()
>> mutate array.sort()
>> let median = array.medianValue() 
> 
> Yes, I think mutating code should be written in many statements rather than 
> squeezing everything into one long expression.
> 
> Indeed, no currently working method chaining would be disallowed in my 
> proposal. Let's consider the example of "fluent API" for value types, i.e. 
> one where you'd extensively `return self` in `mutating` methods. Firstly, the 
> stdlib doesn't practice that at all. And I failed to find any popular Swift 
> libraries that would do so on Github either. The reason is simple: fluent 
> mutating APIs on value types don't work.
> 
> Consider the following silly example that shortens an array in half (but 
> demonstrates the use of `return self` in a `mutating` method):
> 
> extension Array {
> mutating func halve() -> Array {
> self = self[0 ..< count / 2]
> return self
> }
> }
> 
> Suppose I want to get the result of halving an array twice. What happens?
> 
> var xs = [1,2,3,4,5,6,7,8]
> xs.halve().halve()
> // error: cannot use mutating member on immutable value: function call 
> returns immutable value
> 
> So no, fluent APIs on value types are not a thing in Swift. Not now at least. 
> Making mutation explicit along this proposal has nothing to do with fluent 
> APIs.

But is this limitation as per design, or just something that no one reported as 
a bug yet? When acting on large piece of data and simple operations one might 
want to chain mutable version (to avoid large allocation) of the operations as 
a single stream (à la functional programming)  instead of having to use 
multiple line of:
  mutate largeData.operation()

On a side note, this "long" explicit 'mutate' keyword could be seen by some as 
a way to impose the use immutability by making it harder (more to type) to use 
mutability.

Also, this 'mutate' could maybe help to differentiate between sort() 2.2-style 
and sort() 3.0-style, and avoid endless discussion on InPlace/form/ed/ing. But 
for language uniformity, would this new 'mutate' keyword be required on nearly 
every single standard OOP methods?

mutate graph.pencil.changeColor(Red) // the color properties of pencil is 
mutated
mutate graph.pencil.changeWidth(wide)
mutate graph.drawFrame() // the graphic is altered/mutated

Not proposing, just asking.

Dany

> 
>> Alternately you could replace the method invocation operator with &
>> 
>> let median = foo.calculateBigHugeArray()&sort().medianValue()
> 
> Don't you think that's too prone to getting mixed up with the binary `&` 
> operator?
> 
>> Also, if you wanted to stick with consistent & syntax, you could do:
>> 
>> &c.frobnicate(i)
>> and 
>> let k = &c.frobnicate(&i)
> 
> 
> Yeah, probably. However, one place where that notation falls short compared 
> to a prefixing keyword like `mutate` is when mutating `self`:
> 
> extension Array {
> // Apologies for not having the time to think of a less contrived 
> example than this!
> mutating func quarter() {
> mutate self.halve() // Ever since SE-0009, it's unusual to use 
> `self` here.
> mutate halve()  // Where would you put the `&` prefix in this?
> }
> }
> 
> — Pyry
> 
> ___
> 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] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Apr 28, 2016, at 6:20 PM, Xiaodi Wu  wrote:
> 
> On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun  > wrote:
> Can you give me a specific example of where this approach fails for you?
> 
> -- E
> 
> 
> Sure, I'll describe one (renaming some things for clarity and stripping out 
> the meat of the code, because it's not relevant and because it's not 
> elegant)--
> 
> In one file, I have:
> 
> ```
> class PortedTransfom {
> // this class was ported from C++
> // it transforms input FP values to output values in a complicated way
> // it's a standalone entity and the algorithm is even under patent
> // (not owned by me, though it's legal for me to use it for my purposes)
> // for this reason, this ported code lives in its own file
> }
> ```
> 
> In another file, I have:
> 
> ```
> class MyAsinhTransform {
> // this class was written by me
> // nothing earth-shattering here
> }
> 
> class MyLogTransform {
> // also written by me
> }
> 
> class MyLinearTransform {
> // also written by me
> }
> ```
> 
> Transforming values one-at-a-time isn't fast enough, so in another file, I 
> have:
> 
> ```
> import Accelerate
> 
> protocol AcceleratedTransform {
>   func scale(_: [Double]) -> [Double]
>   func unscale(_: [Double]) -> [Double]
> // other functions here
> // some are already implemented in PortedTransform, though
> }
> extension AcceleratedTransform {
> // default implementations for some functions
> // but not `scale(_:)` and `unscale(_:)`, obviously
> }
> 
> extension MyAsinhTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
> 
> extension MyLogTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
> 
> extension  MyLinearTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> // and override some default implementations
> }
> 
> extension PortedTransform : AcceleratedTransform {
> // use BLAS to implement scale(_:) and unscale(_:)
> }
> ```

I think I'm missing something here in terms of a question.  Your imported stuff 
is your imported stuff.
Your extension implements "required" elements but not scale or unscale.

If you extend MyAsinhTransform, you do required but not override for 
scale/unscale. You do required override for anything you replace from 
AcceleratedTransform.
What is BLAS? And what are you specifically asking about?

-- E, apologizing for not understanding

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Andrew Bennett via swift-evolution]

Thanks for clarifying, my responses are inline.

On Fri, Apr 29, 2016 at 10:51 AM, Erica Sadun  wrote:

>
> On Apr 28, 2016, at 6:44 PM, Andrew Bennett  wrote:
>
> Hey, what annotations would I have in this case:
>
> Module 1:
>
> Type AType { func foo() { ... } }
>
> Module 2:
>
> import Module1protocol A { func foo() {...default...} }extension AType: A {}
>
>
>
> No annotations. AType's implementation of foo is unrelated to its
> conformance, which is satisfied by its existing foo method.
>

Thanks, that resolves my misunderstanding. I thought there would need to be
an override or similar.


>
>
> Also, for your *alternatives* section:
>
> protocol A { func foo() {...default...} }Type AType: A {
> func A.foo() {...replacement...}
> }
>
>
> I actually prefer this alternative, I think it fixes many issues.
>
>
> Protocol default implementations do not yet exist.
>
> In this second, you're suggesting instead of doing "override required",
> you use a naming approach that ties the implementation the specific
> protocol. I'm not really won over by this approach:
>
> * It does clarify why the method is included
> * It does not clarify that the method overrides an existing implementation.
>
I agree with this, your `override` keyword would work well here.

* It could be more easily confused when members are required by multiple
> protocols.
>
I see this as a feature. I think this member should *only* implement it for
a single protocol.

If you have the same member in multiple protocols, then they potentially
(probably) do different things. They may want different implementations. If
the member is meant to represent the same thing, then it should be
extracted into a common protocol.


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

Re: [swift-evolution] Extending init checks for property initialization

[David Sweeris via swift-evolution]

Eh, “going away” might be too strong… They’re changing a lot. There’s still the 
extra overhead though.
> On Apr 28, 2016, at 7:49 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> I think I like this idea. It is clear that it is init() and 'defer' says 
>> that it is called at the end of each init. IMO we need exactly some kind of 
>> 'init' as only in init we can set un-initialized stored properties.
>> 
>> But, why implicitly unwrapped optionals are not solution here? I.e.
> 
> To avoid the extra overhead. Also, they’re sorta going away in Swift 3: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
> 
> - Dave Sweeris
> ___
> 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] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Apr 28, 2016, at 6:44 PM, Andrew Bennett  wrote:
> 
> Hey, what annotations would I have in this case:
> 
> Module 1:
> Type AType { func foo() { ... } }
> Module 2:
> import Module1
> protocol A { func foo() {...default...} }
> extension AType: A {}
> 

No annotations. AType's implementation of foo is unrelated to its conformance, 
which is satisfied by its existing foo method.


> Also, for your alternatives section:
> 
> protocol A { func foo() {...default...} }
> Type AType: A {
> func A.foo() {...replacement...}
> }
> 
> I actually prefer this alternative, I think it fixes many issues.

Protocol default implementations do not yet exist.  

In this second, you're suggesting instead of doing "override required", you use 
a naming approach that ties the implementation the specific protocol. I'm not 
really won over by this approach:

* It does clarify why the method is included
* It does not clarify that the method overrides an existing implementation.
* It could be more easily confused when members are required by multiple 
protocols.

-- E

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

Re: [swift-evolution] Extending init checks for property initialization

[David Sweeris via swift-evolution]

> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I think I like this idea. It is clear that it is init() and 'defer' says that 
> it is called at the end of each init. IMO we need exactly some kind of 'init' 
> as only in init we can set un-initialized stored properties.
> 
> But, why implicitly unwrapped optionals are not solution here? I.e.

To avoid the extra overhead. Also, they’re sorta going away in Swift 3: 
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Andrew Bennett via swift-evolution]

Hey, what annotations would I have in this case:

Module 1:

Type AType { func foo() { ... } }

Module 2:

import Module1protocol A { func foo() {...default...} }extension AType: A {}



Also, for your *alternatives* section:

protocol A { func foo() {...default...} }Type AType: A {
func A.foo() {...replacement...}
}


I actually prefer this alternative, I think it fixes many issues.


On Thu, Apr 28, 2016 at 12:47 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 27, 2016, at 6:03 PM, Douglas Gregor  wrote:
>
> 2) Is “override” only required when there is a default implementation of
> the protocol requirement, or is it required whenever you are implementing a
> protocol requirement?
>
>
> Override is only because it is overriding the default implementation of
> the protocol requirement. Without that default implementation there would
> be no override, it would simply be satisfying the requirement.
>
>
> For me, this doesn’t provide additional value of “required”: i.e., the
> value of having a keyword here is in telling me that I failed to implement
> a requirement when I’ve clearly said that I wanted to implement a
> requirement. Whether there was a default there or not isn’t really very
> interesting. Plus, a default could be added later to a requirement that I
> implement: that change has zero impact on how my code works (before or
> after), but now I’d be require to add an “override” keyword when I
> recompile.
>
> Contrast that with classes: if you recompile against a new version of a
> library and the compiler tells you that you need to add “override”, it’s
> serious because the semantics of your program will change if you’re now
> overriding something that you weren’t before.
>
>
> Consider these situations:
>
> * I use the word 'required' but I use a Double in the signature instead of
> a Float. Compiler detects. Instant alert on the mismatch.
> * I implement a required member but fail to use the word required.
> Compiler detects. Instant alert: this is a required member, did you intend
> to use this signature for that purpose?
> * I implement a required member. I then later provide a default. Compiler
> detects. "This version will be overridden by the default version the
> protocol and/or extension. Either remove this implementation or add the
> override keyword to prefer it to the default version."
> * I implement a default version and then later implement the required
> member. Compiler detects Same warning as above.
>
>
>
>
> * If the former, it might be the case that it’s too easy to forget to add
> the “override” keyword (because it’s needed for some implementations of
> protocol requirements but not others), which undercuts the value of having
> it.
>
>
> Forcing the override keyword makes it clear at the definition point that
> the story extends beyond the method or whatever to point to a default
> implementation that is being replaced. I *really* like having that
> reference in terms of both code construction (“I am doing this as a
> deliberate act”) with the compiler complaining otherwise, and in terms of
> code self documentation (“I know this was added deliberately, what default
> did it override?”)
>
>
> I see the former (“I am doing this as a deliberate act”)  as a very common
> complaint; the latter not nearly as much. What motivates that? And does it
> justify adding a *second* keyword to these declarations?
>
>
> I think I caught the gist in the situations above. If not, will respond
> further.
>
>
> I’d also like to bring up two related topics, although they probably
> should at some point move to their own thread if they have any legs:
>
>
> Related topic 1: How should a consumer handle a situation where two
> unrelated protocols both require the same member and offer different
> default implementations. Can they specify which implementation to accept or
> somehow run both?
>
> type B: A, C {
> override required func foo() { A.foo(); C.foo() }
> }
>
>
> I think the right answer here is for the compiler to produce an ambiguity
> if you don’t implement the requirement yourself, and then solving your
> “related topic 2” lets you choose which implementation you want.
>
>
> How do you choose which one? What syntax? For example:
>
> required func foo = A.foo
>
> would be the simplest approach
>
>
> type B: A, C {
>   override required func foo() { A.foo(self)() }
> }
>
>
> +1
>
>
> Related topic 2: How can a consumer “inherit” the behavior of the default
> implementation (like calling super.foo() in classes) and then extend that
> behavior further. This is a bit similar to how the initialization chaining
> works. I’d like to be able to call A.foo() and then add custom follow-on
> behavior rather than entirely replacing the behavior.
>
> type B: A {
> override required func foo() { A.foo(); … my custom behavior … }
> }
>
>
> Seems totally reasonable to me. One ugly syntax: A.foo(self)(), leveraging
> the currying of self?
>
>
> Ugly but it w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0017: Change Unmanaged to use UnsafePointer

[Andrew Trick via swift-evolution]

> On Apr 28, 2016, at 11:10 AM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and 
> runs through May 3. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md


I have some concerns, but let me just suggest a simple alternative and see what 
people think...

- Leave the existing from/toOpaque API until we can come up with a better plan 
for moving away from OpaquePointer.

- Add initializers to avoid boilerplate, but only for "safe" variants of the 
cast:

extension Unmanaged {
  @_transparent
  public init(_ from : UnsafePointer)

  @_transparent
  public init?(_ from : UnsafePointer?)
}

extension UnsafeMutablePointer where Pointee : AnyObject {
  @_transparent
  public init(_ from : Unmanaged)

  @_transparent
  public init?(_ from : Unmanaged?)
}

- This doesn't solve the stated problem of passing unmanaged pointers to 
'void*' imports. Is that really an issue? I believe the correct fix is to stop 
importing 'void*' as UnsafePointer. We should have a nominally distinct 
"opaque" pointer type, 'void*' should be imported as that type, and casting 
from any UnsafePointer to the opaque pointer type should be inferred and 
implicit for function arguments. I can send a proposal for eliminating 
UnsafePointer next week, but the scope of that proposal will be much 
broader.

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun  wrote:

> Can you give me a specific example of where this approach fails for you?
>
> -- E
>


Sure, I'll describe one (renaming some things for clarity and stripping out
the meat of the code, because it's not relevant and because it's not
elegant)--

In one file, I have:

```
class PortedTransfom {
// this class was ported from C++
// it transforms input FP values to output values in a complicated way
// it's a standalone entity and the algorithm is even under patent
// (not owned by me, though it's legal for me to use it for my purposes)
// for this reason, this ported code lives in its own file
}
```

In another file, I have:

```
class MyAsinhTransform {
// this class was written by me
// nothing earth-shattering here
}

class MyLogTransform {
// also written by me
}

class MyLinearTransform {
// also written by me
}
```

Transforming values one-at-a-time isn't fast enough, so in another file, I
have:

```
import Accelerate

protocol AcceleratedTransform {
  func scale(_: [Double]) -> [Double]
  func unscale(_: [Double]) -> [Double]
// other functions here
// some are already implemented in PortedTransform, though
}
extension AcceleratedTransform {
// default implementations for some functions
// but not `scale(_:)` and `unscale(_:)`, obviously
}

extension MyAsinhTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension MyLogTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension  MyLinearTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension PortedTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
}
```

On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm not sure that I'm entirely happy with this distinction between already
> compiled types and ones that have not yet been compiled. It's a common
> Swift idiom to implement protocol requirements in extensions, which
> encourages a kind of modularity, if you will. Every so often (and maybe
> this isn't best practice), I incorporate third-party code into a project in
> source form and not as a compiled library (with attribution, and in
> compliance with the license, etc., obviously). Often these are little
> snippets, perhaps useful helper functions or types. The beauty of
> extensions is that I can extend these as necessary without touching the
> original code. The point is, here one would not be able to implement
> certain things in that way if this proposal is adopted. To say that the
> workaround is just editing the original code is deeply unsatisfying,
> because it would be equally valid to say that the same workaround applies
> to stripping out extensions altogether for non-imported types.
>
>
> On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> It is a good idea to explicitly document the behaviour that this
>> requirement for override is a compile time check only and does not mean
>> that already compiled code has to be recompiled to allow a protocol to be
>> retroactively fitted to an already compiled type.
>>
>>
>> On Friday, 29 April 2016, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Apr 28, 2016, at 5:49 PM, Erica Sadun  wrote:
>>>
>>>
>>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson 
>>> wrote:
>>> We can't add the keywords if the structs are defined in a module we
>>> import but don't own.  We are only declaring the conformance
>>> retroactively.  The ability to do this is a crucial aspect of generic
>>> programming.  It isn't yet clear how your proposal handles retroactive
>>> modeling.
>>>
>>>
>>> These are compile-time checks and should not affect compiled code.
>>>
>>>
>>> Does that mean the conformance declaration will be accepted by the
>>> compiler under your proposal?  I would really like to see this called out
>>> explicitly in the proposal.
>>>
>>>
>>> -- E
>>>
>>>
>>
>> --
>> -- Howard.
>>
>> ___
>> 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] [Proposal] Add Binary Search functions to SequenceType

[Jeff Hajewski via swift-evolution]

Dave - I think it boils down to a gap in communication. We were under the
impression that the goal was a pure extension of CollectionType, without
making any requirements on Generator.Element (i.e., your requiring it to be
comparable), where binary search, lower bound, and upper bound all work
with the same unary predicate. Of course, as you demonstrated, it is
trivial to implement when Generator.Element is Comparable, but if you relax
that requirement it is not possible to create a set of functions (binary
search, lower bound, upper bound) that all take the same unary predicate.
We ultimately came up with a slightly different approach, implementing
binary search similar to your example, but a different take on lower bound,
upper bound, and range. I suppose we should just send out our proposal and
get everyone's take on it.

Jeff

On Thu, Apr 28, 2016 at 5:06 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Thu Apr 28 2016, Jeff Hajewski  wrote:
>
> > Thanks for bringing this back into the spotlight Pyry. A few of us have
> been
> > working on this issue here:
> >
> > https://github.com/lorenzoracca/Swift-binary-search
> >
> > However we have sort of stalled as we have been unable to come up with a
> unary
> > approach that Dave suggested using just Bool return values. And of
> course, as
> > you say, the three case order enum would make this a trivial problem.
> >
> > I guess the question is, do we move forward without a unary
> implementation and
> > update if/when we get a three case Order enum or do we wait on a three
> case
> > Order enum and implement a fully generic version once?
>
> Or you could just do it like this (Swift 2.2-compatible).  Am I missing
> something?
>
> extension CollectionType {
>   /// Returns the index of the first element satisfying `predicate`,
>   /// or `endIndex` if no such element exists.
>   ///
>   /// - Requires: `self` is partitioned with respect to `predicate`;
>   ///   that is, there exists an index `i` in `startIndex...endIndex`
>   ///   such that `predicate` returns `false` for every element of
>   ///   `self[startIndex..   ///   of `self[i..   @warn_unused_result
>   public func binarySearch(
> predicate: (Self.Generator.Element)->Bool
>   ) -> Index {
> var len = count
> var min = startIndex
> while len > 0 {
>   let half = len/2
>   let middle = min.advancedBy(half)
>
>   if !predicate(self[middle]) {
> min = middle.successor()
> len -= half.successor()
>   } else {
> len = half
>   }
> }
> return min
>   }
> }
>
> extension CollectionType where Generator.Element : Comparable {
>   /// Returns the index of the first element greater than or equal to
>   /// `target`, or `endIndex` if no such element exists.
>   ///
>   /// - Requires: `self` is sorted.
>   @warn_unused_result
>   public func lowerBound(target: Self.Generator.Element) -> Index {
> return binarySearch { $0 >= target }
>   }
>
>   /// Returns the index of the first element greater than
>   /// `target`, or `endIndex` if no such element exists.
>   ///
>   /// - Requires: `self` is sorted.
>   @warn_unused_result
>   public func upperBound(target: Self.Generator.Element) -> Index {
> return binarySearch { $0 > target }
>   }
> }
>
> //===--- TEST IT
> --===//
> import Darwin
> for _ in 0..<1000 {
>   // build a sorted array of up to 30 values in the range 0..<10
>   var a : Array = []
>   for _ in 0.. a.append(Int(arc4random_uniform(10)))
>   }
>   a.sortInPlace()
>
>   print(a)
>
>   for i in -3...14 {
> let l = a.lowerBound(i)
> let u = a.upperBound(i)
> assert(l >= 0)
> assert(u <= a.count)
> assert(l <= u)
> if l > 0 {
>   assert(a[l - 1] < i)
> }
> if l < a.count {
>   assert(a[l] >= i)
> }
> if u > 0 {
>   assert(a[u - 1] <= i)
> }
> if u < a.count {
>   assert(a[u] > i)
> }
>   }
> }
>
> --
> Dave
>
> ___
> 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] Requiring proactive overrides for default protocol implementations.

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 28, 2016, at 6:20 PM, Erica Sadun  wrote:
> 
> 
>>> On Friday, 29 April 2016, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> Does that mean the conformance declaration will be accepted by the compiler 
>>> under your proposal?  I would really like to see this called out explicitly 
>>> in the proposal.
> 
> I'm making live updates at the gist in response to on-list discussions:
> 
> https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a
> 
> If you have specific suggestions for modifications, I'll be happy to evaluate 
> for incorporation.

Unfortunately I don't have specific suggestions as there are flaws with all of 
the approaches I can think of.  However, I do think *something* needs to be 
specified regarding behavior when retroactively conforming a type from a 
different module which doesn't know anything about the protocol but does 
implement the requirements (as normal methods).  I can't determine how I feel 
about this proposal without seeing it clearly specified.



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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

Why allow both `override` and `required`? I understand you mean it to
indicate that you're overriding a requirement, but does that provide any
additional safety? Both say "I intend to name something the same as
something else."

In addition, the juxtaposition of both keywords can be misunderstood.
Specifically: required suggests that something not otherwise there must be
there. Override suggests that there's already something there. The act of
overriding can never itself be "required." It's could be thought of as an
oxymoron to have both, no?

On Thu, Apr 28, 2016 at 6:20 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Friday, 29 April 2016, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Does that mean the conformance declaration will be accepted by the
>> compiler under your proposal?  I would really like to see this called out
>> explicitly in the proposal.
>>
>
> I'm making live updates at the gist in response to on-list discussions:
>
> https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a
>
> If you have specific suggestions for modifications, I'll be happy to
> evaluate for incorporation.
>
> -- 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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

Can you give me a specific example of where this approach fails for you?

-- E


> On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I'm not sure that I'm entirely happy with this distinction between already 
> compiled types and ones that have not yet been compiled. It's a common Swift 
> idiom to implement protocol requirements in extensions, which encourages a 
> kind of modularity, if you will. Every so often (and maybe this isn't best 
> practice), I incorporate third-party code into a project in source form and 
> not as a compiled library (with attribution, and in compliance with the 
> license, etc., obviously). Often these are little snippets, perhaps useful 
> helper functions or types. The beauty of extensions is that I can extend 
> these as necessary without touching the original code. The point is, here one 
> would not be able to implement certain things in that way if this proposal is 
> adopted. To say that the workaround is just editing the original code is 
> deeply unsatisfying, because it would be equally valid to say that the same 
> workaround applies to stripping out extensions altogether for non-imported 
> types.
> 
> 
> On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> It is a good idea to explicitly document the behaviour that this requirement 
> for override is a compile time check only and does not mean that already 
> compiled code has to be recompiled to allow a protocol to be retroactively 
> fitted to an already compiled type.
> 
> 
> On Friday, 29 April 2016, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
> Sent from my iPad
> 
> On Apr 28, 2016, at 5:49 PM, Erica Sadun > wrote:
> 
>> 
>>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson > 
>>> wrote:
>>> We can't add the keywords if the structs are defined in a module we import 
>>> but don't own.  We are only declaring the conformance retroactively.  The 
>>> ability to do this is a crucial aspect of generic programming.  It isn't 
>>> yet clear how your proposal handles retroactive modeling.
>> 
>> These are compile-time checks and should not affect compiled code.
> 
> Does that mean the conformance declaration will be accepted by the compiler 
> under your proposal?  I would really like to see this called out explicitly 
> in the proposal.
> 
>> 
>> -- E
>> 
> 
> 
> -- 
> -- Howard.
> 
> ___
> 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] [Pitch] Allow nested protocol declarations

[David Sweeris via swift-evolution]

> On Apr 28, 2016, at 6:27 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Note that this cannot work when any enclosing type is generic, e.g.,
> 
> class MyController {
>   protocol Delegate {
> // I’ve just created a parameterized protocol!
>   }
> }
> 
> Otherwise, I don’t see any issues with the proposal, and I like that it 
> eliminates a large number of top-level names.
> 
>   - Doug

Is that a bad, or are you just pointing out that this proposal would implicitly 
add parameterized protocols to Swift? I don’t think they’re *exactly* the same 
as “naked” parameterized protocols, since you wouldn’t be able access a nested 
protocol without specifying all the container type’s generic parameters, but 
maybe that’s a difference that makes no difference.

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Howard Lovatt via swift-evolution]

To get over issues like the inner protocol accessing outer quantities like
properties and generics you could add keyword noaccess (bike-shedding
name) to the declaration to make it clear that it does not have access,
e.g.:

class MyController {
  noaccess protocol Delegate {
// No access to T
  }
}

Java does something along these lines using static and it works out well.
As an aside static is insufficient in Swift because statics have access to
generics in Swift, unlike Java.

On Friday, 29 April 2016, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Type nesting allows some convenient and straightforward semantics that we
> see inside the Swift standard library such as views on String like
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
> cannot be nested in a type and gives a non-obvious error that the
> “Declaration is only valid at file scope.” Just as other nested types allow
> proper contextual scoping, a nested protocol could make a lot sense for a
> number of patterns. For example, there are many “Delegate” protocols
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
> before and after type nesting:
>
> // Without type nesting
>
> protocol MyControllerDelegate : class {
>
> }
>
> class MyController {
>
> weak var delegate: MyControllerDelegate?
>
> }
>
> // With type nesting
>
> class MyController {
>
> weak var delegate: Delegate?
>
> protocol Delegate : class {
>
> }
>
> }
>
> Though the change is mostly semantics, it does allow an explicit
> association between My Controller and the Delegate instead of only a named
> association. It also cleans up the module name space like other nested
> types and makes associated protocols more discoverable in my opinion.
>
> I’d love to hear everyone’s thoughts.
>
>
> Note that this cannot work when any enclosing type is generic, e.g.,
>
> class MyController {
>   protocol Delegate {
> // I’ve just created a parameterized protocol!
>   }
> }
>
>
> Otherwise, I don’t see any issues with the proposal, and I like that it
> eliminates a large number of top-level names.
>
> - Doug
>
>
>

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Douglas Gregor via swift-evolution]

> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution 
>  wrote:
> 
> Type nesting allows some convenient and straightforward semantics that we see 
> inside the Swift standard library such as views on String like 
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol 
> cannot be nested in a type and gives a non-obvious error that the 
> “Declaration is only valid at file scope.” Just as other nested types allow 
> proper contextual scoping, a nested protocol could make a lot sense for a 
> number of patterns. For example, there are many “Delegate” protocols 
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern before 
> and after type nesting:
> 
> // Without type nesting
> 
> protocol MyControllerDelegate : class {
> 
> }
> 
> class MyController {
> 
> weak var delegate: MyControllerDelegate?
> 
> }
> 
> // With type nesting
> 
> class MyController {
> 
> weak var delegate: Delegate?
> 
> protocol Delegate : class {
> 
> }
> 
> }
> 
> Though the change is mostly semantics, it does allow an explicit association 
> between My Controller and the Delegate instead of only a named association. 
> It also cleans up the module name space like other nested types and makes 
> associated protocols more discoverable in my opinion. 
> 
> I’d love to hear everyone’s thoughts.

Note that this cannot work when any enclosing type is generic, e.g.,

class MyController {
  protocol Delegate {
// I’ve just created a parameterized protocol!
  }
}

Otherwise, I don’t see any issues with the proposal, and I like that it 
eliminates a large number of top-level names.

- Doug


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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

I'm not sure that I'm entirely happy with this distinction between already
compiled types and ones that have not yet been compiled. It's a common
Swift idiom to implement protocol requirements in extensions, which
encourages a kind of modularity, if you will. Every so often (and maybe
this isn't best practice), I incorporate third-party code into a project in
source form and not as a compiled library (with attribution, and in
compliance with the license, etc., obviously). Often these are little
snippets, perhaps useful helper functions or types. The beauty of
extensions is that I can extend these as necessary without touching the
original code. The point is, here one would not be able to implement
certain things in that way if this proposal is adopted. To say that the
workaround is just editing the original code is deeply unsatisfying,
because it would be equally valid to say that the same workaround applies
to stripping out extensions altogether for non-imported types.


On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> It is a good idea to explicitly document the behaviour that this
> requirement for override is a compile time check only and does not mean
> that already compiled code has to be recompiled to allow a protocol to be
> retroactively fitted to an already compiled type.
>
>
> On Friday, 29 April 2016, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Apr 28, 2016, at 5:49 PM, Erica Sadun  wrote:
>>
>>
>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson 
>> wrote:
>> We can't add the keywords if the structs are defined in a module we
>> import but don't own.  We are only declaring the conformance
>> retroactively.  The ability to do this is a crucial aspect of generic
>> programming.  It isn't yet clear how your proposal handles retroactive
>> modeling.
>>
>>
>> These are compile-time checks and should not affect compiled code.
>>
>>
>> Does that mean the conformance declaration will be accepted by the
>> compiler under your proposal?  I would really like to see this called out
>> explicitly in the proposal.
>>
>>
>> -- E
>>
>>
>
> --
> -- Howard.
>
> ___
> 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] Extending init checks for property initialization

[Howard Lovatt via swift-evolution]

I like the `defer init` idea but suggest you have to explicitly call it at
the end of all the other non-convenience `init`s. The advantage of an
explicit call are two fold:

  1. It is obvious what is happening
  2. You can pass arguments

On Friday, 29 April 2016, Basem Emara via swift-evolution <
swift-evolution@swift.org> wrote:

> I see what you’re saying and the forced optionals is pretty inconvenient.
>
> As far as syntax, how about more of a “deferred” init that gets triggered
> regardless like this:
>
> defer init() {
> // Always gets called no matter what designated init triggers
> }
>
> > On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> > Consider a relatively-common init pattern:
> >
> > class SomeViewController: UIViewController {
> >
> >// MARK: Properties
> >
> >private var videoPlayer: AVPlayer
> >private var videoPlayerLayer: AVPlayerLayer
> >
> >// MARK: - Object Lifecycle
> >
> >override init(nibName: String?, bundle nibBundle: NSBundle?) {
> >super.init(nibName: nibName, bundle: nibBundle)
> >
> >commonInitialization()
> >}
> >
> >required init?(coder decoder: NSCoder) {
> >super.init(coder: decoder)
> >
> >commonInitialization()
> >}
> >
> >private func commonInitialization() {
> >videoPlayer = AVPlayer(...)
> >videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
> >}
> >
> > }
> >
> > This does not work. Both properties are non-optional, and the compiler
> complains that they are not initialized in either init method. It seems
> rather common to want a single point of contact regarding object
> initialization, regardless of the path taken to initialize that object.
> Ideally, objects could all be funneled to one designated initializer, but
> this isn’t always the case.
> >
> > What are people’s thoughts about either a specialized function that is
> always called at the very end of each object’s lifecycle OR some sort of
> attribute for a function that hints that the compiler should follow it if
> called in an init function to check for property initialization?
> >
> > func commonInit() {
> >
> > }
> >
> > or
> >
> > @extend_init private func commonInitialization() {
> >
> > }
> > ___
> > 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
>


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

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

[Patrick Smith via swift-evolution]

* What is your evaluation of the proposal?

Yes, seems like a great addition. I have wanted a method like this quite a few
times.

  

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

Yes, I think it adds an essential part to Sequence.

  

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

Yes, it’s surprising it wasn’t there already; it feels a very natural
addition.

  

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

.find() is the name I have seen elsewhere, and this proposed functionality is
the same.

  

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

A quick reading, and had followed some earlier discussion.

  
**Patrick Smith**  

On Apr 29 2016, at 4:11 am, Chris Lattner via swift-evolution  wrote:  

> Hello Swift community,

>

> The review of "SE-0032: Add find method to SequenceType" begins now and runs
through May 3. The proposal is available here:

>

> https://github.com/apple/swift-evolution/blob/master/proposals/0032
-sequencetype-find.md

>

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

>

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

>

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

>

> What goes into a review?

>

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

>

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

> More information about the Swift evolution process is available at

>

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

>

> 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] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Friday, 29 April 2016, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Does that mean the conformance declaration will be accepted by the compiler 
> under your proposal?  I would really like to see this called out explicitly 
> in the proposal.

I'm making live updates at the gist in response to on-list discussions:

https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a 


If you have specific suggestions for modifications, I'll be happy to evaluate 
for incorporation.

-- E

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

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[Brent Royal-Gordon via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

>   • What is your evaluation of the proposal?

I think this change is overly fussy, but not the end of the world.

I enjoy this convenience, but I can live without it. I hope that, when the dust 
settles from all our parameter changes, we can reintroduce it in some form.

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

It seems insignificant to me, but I support small syntax clean-ups in general.

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

Arguably it does, at least for the current parameter-handling retrenchment.

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

Participated in previous discussion.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Howard Lovatt via swift-evolution]

+1

Main part of proposal: Not sure that you need the required keyword,
overload alone has proven sufficient in Java for the same feature.

Related features: For calling default implementations in inherited
protocols I think this is a valuable feature but should be a seperate
thread.

On Thursday, 28 April 2016, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> From the Swift Programming Language: *Methods on a subclass that override
> the superclass’s implementation are marked with override—overriding a
> method by accident, without override, is detected by the compiler as an
> error. The compiler also detects methods with override that don’t actually
> override any method in the superclass.*
>
> I would like to extend this cautious approach to protocols, forcing the
> developer to deliberately override an implementation that’s inherited from
> a protocol extension. This would prevent accidental overrides and force the
> user to proactively choose to implement a version of a protocol member that
> already exists in the protocol extension.
>
> I envision this as using the same `override` keyword that’s used in class
> based inheritance but extend it to protocol inheritance:
>
> protocol A {
> func foo()
> }
>
> extension A {
> func foo() { .. default implementation … }
> }
>
> type B: A {
>
> override required func foo () { … overrides implementation … }
> }
>
>
> I’d also like to bring up two related topics, although they probably
> should at some point move to their own thread if they have any legs:
>
> Related topic 1: How should a consumer handle a situation where two
> unrelated protocols both require the same member and offer different
> default implementations. Can they specify which implementation to accept or
> somehow run both?
>
> type B: A, C {
> override required func foo() { A.foo(); C.foo() }
> }
>
> Related topic 2: How can a consumer “inherit” the behavior of the default
> implementation (like calling super.foo() in classes) and then extend that
> behavior further. This is a bit similar to how the initialization chaining
> works. I’d like to be able to call A.foo() and then add custom follow-on
> behavior rather than entirely replacing the behavior.
>
> type B: A {
> override required func foo() { A.foo(); … my custom behavior … }
> }
>
> cc’ing in Jordan who suggested a new thread on this and Doug, who has
> already expressed some objections so I want him to  have the opportunity to
> bring that discussion here.
>
> — E
>


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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

On Apr 28, 2016, at 5:09 PM, Howard Lovatt  wrote:
> 
> It is a good idea to explicitly document the behaviour that this requirement 
> for override is a compile time check only and does not mean that already 
> compiled code has to be recompiled to allow a protocol to be retroactively 
> fitted to an already compiled type.
> 

At this time, default protocol implementations do not exist.

At compilation time, either a protocol default exists or it does not. The goal 
of this proposal is to increase safety through syntax. 

What is the current behavior where a subclass is pre-compiled and the 
superclass then changes through an extension to implement a member that the 
already compiled subclass had implemented but not as an override?

-- E


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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Howard Lovatt via swift-evolution]

It is a good idea to explicitly document the behaviour that this
requirement for override is a compile time check only and does not mean
that already compiled code has to be recompiled to allow a protocol to be
retroactively fitted to an already compiled type.

On Friday, 29 April 2016, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Apr 28, 2016, at 5:49 PM, Erica Sadun  > wrote:
>
>
> On Apr 28, 2016, at 12:18 PM, Matthew Johnson  > wrote:
> We can't add the keywords if the structs are defined in a module we import
> but don't own.  We are only declaring the conformance retroactively.  The
> ability to do this is a crucial aspect of generic programming.  It isn't
> yet clear how your proposal handles retroactive modeling.
>
>
> These are compile-time checks and should not affect compiled code.
>
>
> Does that mean the conformance declaration will be accepted by the
> compiler under your proposal?  I would really like to see this called out
> explicitly in the proposal.
>
>
> -- E
>
>

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 28, 2016, at 5:49 PM, Erica Sadun  wrote:
> 
> 
>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson  wrote:
>> We can't add the keywords if the structs are defined in a module we import 
>> but don't own.  We are only declaring the conformance retroactively.  The 
>> ability to do this is a crucial aspect of generic programming.  It isn't yet 
>> clear how your proposal handles retroactive modeling.
> 
> These are compile-time checks and should not affect compiled code.

Does that mean the conformance declaration will be accepted by the compiler 
under your proposal?  I would really like to see this called out explicitly in 
the proposal.

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Tony Allevato via swift-evolution]

+1, would love to see UIKit's (and other frameworks') delegates/datasources
nested like this one day.

It seems like there's nothing that should prevent nesting like this; it's
just going to produce a different mangled name.


On Thu, Apr 28, 2016 at 10:15 AM Brad Hilton via swift-evolution <
swift-evolution@swift.org> wrote:

> Type nesting allows some convenient and straightforward semantics that we
> see inside the Swift standard library such as views on String like
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
> cannot be nested in a type and gives a non-obvious error that the
> “Declaration is only valid at file scope.” Just as other nested types allow
> proper contextual scoping, a nested protocol could make a lot sense for a
> number of patterns. For example, there are many “Delegate” protocols
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
> before and after type nesting:
>
> // Without type nesting
>
> protocol MyControllerDelegate : class {
>
>
> }
>
> class MyController {
>
>
> weak var delegate: MyControllerDelegate?
>
>
> }
>
> // With type nesting
>
> class MyController {
>
>
> weak var delegate: Delegate?
>
>
> protocol Delegate : class {
>
>
> }
>
>
> }
>
> Though the change is mostly semantics, it does allow an explicit
> association between My Controller and the Delegate instead of only a named
> association. It also cleans up the module name space like other nested
> types and makes associated protocols more discoverable in my opinion.
>
> I’d love to hear everyone’s thoughts.
>
> Brad Hilton
> ___
> 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] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> Did you ever really use multiline string literals before?

Yes. I used Perl in the CGI script era. Believe me, I have used every quoting 
syntax it supports extensively, including `'` strings, `"` strings, `q` 
strings, `qq` strings, and heredocs. This proposal is educated by knowledge of 
their foibles.

As outlined in the "Future directions for string literals in general" section, 
I believe alternate delimiters (so you can embed quotes) are a separate feature 
and should be handled in a separate proposal. Once both features are available, 
they can be combined. For instance, using the `_"foo"_` syntax I sketch there 
for alternate delimiters, you could say:

let xml = _"
"
" 
" \(author)
" 
""_

Basically, I am trying very, *very* hard not to let this proposal turn into 
"here's a huge pile of random string literal features which will become a giant 
catfight if we debate them all at once". Clearly this message is not getting 
through, but I'm not sure how I should edit the proposal to make it clear 
enough.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> On Apr 28, 2016, at 12:18 PM, Matthew Johnson  wrote:
> We can't add the keywords if the structs are defined in a module we import 
> but don't own.  We are only declaring the conformance retroactively.  The 
> ability to do this is a crucial aspect of generic programming.  It isn't yet 
> clear how your proposal handles retroactive modeling.

These are compile-time checks and should not affect compiled code.

-- E

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Howard Lovatt via swift-evolution]

+1 very handy to associate types together

On Friday, 29 April 2016, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

> I think that would be a good feature.
>
> > Am 28.04.2016 um 19:15 schrieb Brad Hilton via swift-evolution <
> swift-evolution@swift.org >:
> >
> > Type nesting allows some convenient and straightforward semantics that
> we see inside the Swift standard library such as views on String like
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
> cannot be nested in a type and gives a non-obvious error that the
> “Declaration is only valid at file scope.” Just as other nested types allow
> proper contextual scoping, a nested protocol could make a lot sense for a
> number of patterns. For example, there are many “Delegate” protocols
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
> before and after type nesting:
> >
> > // Without type nesting
> >
> > protocol MyControllerDelegate : class {
> >
> > }
> >
> > class MyController {
> >
> > weak var delegate: MyControllerDelegate?
> >
> > }
> >
> > // With type nesting
> >
> > class MyController {
> >
> > weak var delegate: Delegate?
> >
> > protocol Delegate : class {
> >
> > }
> >
> > }
> >
> > Though the change is mostly semantics, it does allow an explicit
> association between My Controller and the Delegate instead of only a named
> association. It also cleans up the module name space like other nested
> types and makes associated protocols more discoverable in my opinion.
> >
> > I’d love to hear everyone’s thoughts.
> >
> > Brad Hilton
> > ___
> > 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
>


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

Re: [swift-evolution] [Review] SE-0017: Change Unmanaged to use UnsafePointer

[Patrick Smith via swift-evolution]

* What is your evaluation of the proposal?This sounds like a great 
move. I recently used the CFNotificationCenter APIs, where I needed an 
UnsafePointer from an Unmanaged and the process was a bit surprising. Good to 
know first off I was even doing it the correct way, and I think this change 
substantially improves it.
* Is the problem being addressed significant enough to warrant a change 
to Swift?Yes, I imagine the use case of a pointer is the most wanted.
* Does this proposal fit well with the feel and direction of Swift?Each 
part with Unmanaged and UnsafePointer seem well thought out and logical, and 
this change fits in well.
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?The only language 
I can think of is Objective-C, and I think this matches the flow of __bridge 
and const void * well. 
Patrick

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Michael Peternell via swift-evolution]

I think that would be a good feature.

> Am 28.04.2016 um 19:15 schrieb Brad Hilton via swift-evolution 
> :
> 
> Type nesting allows some convenient and straightforward semantics that we see 
> inside the Swift standard library such as views on String like 
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol 
> cannot be nested in a type and gives a non-obvious error that the 
> “Declaration is only valid at file scope.” Just as other nested types allow 
> proper contextual scoping, a nested protocol could make a lot sense for a 
> number of patterns. For example, there are many “Delegate” protocols 
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern before 
> and after type nesting:
> 
> // Without type nesting
> 
> protocol MyControllerDelegate : class {
> 
> }
> 
> class MyController {
> 
> weak var delegate: MyControllerDelegate?
> 
> }
> 
> // With type nesting
> 
> class MyController {
> 
> weak var delegate: Delegate?
> 
> protocol Delegate : class {
> 
> }
> 
> }
> 
> Though the change is mostly semantics, it does allow an explicit association 
> between My Controller and the Delegate instead of only a named association. 
> It also cleans up the module name space like other nested types and makes 
> associated protocols more discoverable in my opinion. 
> 
> I’d love to hear everyone’s thoughts.
> 
> Brad Hilton
> ___
> 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] multi-line string literals.

[Michael Peternell via swift-evolution]

is it just me who would prefer a multiline string literal to not require a 
\backslash before each "double quote"?

Did you ever really use multiline string literals before? I did, and it's 
mostly for quick hacks where I wrote a script or tried something out quickly. 
And maybe I needed to put an XML snippet into a unit test case to see if my 
parser correctly parses or correctly rejects the snippet. The current proposal 
doesn't help this use case in any way. I cannot see which use case inspires 
multiline string literals which require double quotes to be escaped... I 
wouldn't use them if they were available. I'd become an Android developer 
instead ;)

-Michael

> Am 28.04.2016 um 23:56 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
>> Awesome.  Some specific suggestions below, but feel free to iterate in a 
>> pull request if you prefer that.
> 
> I've adopted these suggestions in some form, though I also ended up rewriting 
> the explanation of why the feature was designed as it is and fusing it with 
> material from "Alternatives considered".
> 
> (Still not sure who I should list as a co-author. I'm currently thinking 
> John, Tyler, and maybe Chris? Who's supposed to go there?)
> 
> Multiline string literals
> 
>   • Proposal: SE-
>   • Author(s): Brent Royal-Gordon
>   • Status: Second Draft
>   • Review manager: TBD
> Introduction
> 
> In Swift 2.2, the only means to insert a newline into a string literal is the 
> \n escape. String literals specified in this way are generally ugly and 
> unreadable. We propose a multiline string feature inspired by English 
> punctuation which is a straightforward extension of our existing string 
> literals.
> 
> This proposal is one step in a larger plan to improve how string literals 
> address various challenging use cases. It is not meant to solve all problems 
> with escaping, nor to serve all use cases involving very long string 
> literals. See the "Future directions for string literals in general" section 
> for a sketch of the problems we ultimately want to address and some ideas of 
> how we might do so.
> 
> Swift-evolution threads: multi-line string literals. (April), multi-line 
> string literals (December)
> 
> Draft Notes
> 
>   • Removes the comment feature, which was felt to be an unnecessary 
> complication. This and the backslash feature have been listed as future 
> directions. 
> 
>   • Loosens the specification of diagnostics, suggesting instead of 
> requiring fix-its.
> 
>   • Splits a "Rationale" section out of the "Proposed solution" section.
> 
>   • Adds extensive discussion of other features which wold combine with 
> this one.
> 
>   • I've listed only myself as an author because I don't want to put 
> anyone else's name to a document they haven't seen, but there are others who 
> deserve to be listed (John Holdsworth at least). Let me know if you think you 
> should be included.
> 
> Motivation
> 
> As Swift begins to move into roles beyond app development, code which needs 
> to generate text becomes a more important use case. Consider, for instance, 
> generating even a small XML string:
> 
> let xml = "\n\n\t empty=\"\">\n\t\t\(author)\n\t\n"
> The string is practically unreadable, its structure drowned in escapes and 
> run-together lines; it looks like little more than line noise. We can improve 
> its readability somewhat by concatenating separate strings for each line and 
> using real tabs instead of \t escapes:
> 
> let xml = "\n" +
>  
>   
> "\n" +
>  
>   
> " \n" +
>  
>   
> " \(author)\n" +
>  
>   
> " \n" +
>  
>   
> ""
> However, this creates a more complex expression for the type checker, and 
> there's still far more punctuation than ought to be necessary. If the most 
> important goal of Swift is making code readable, this kind of code falls far 
> short of that goal.
> 
> Proposed solution
> 
> We propose that, when Swift is parsing a string literal, if it reaches the 
> end of the line without encountering an end quote, it should look at the next 
> line. If it sees a quote at the beginning (a "continuation quote"), the 
> string literal contains a newline and then continues on that line. Otherwise, 
> the string literal is unterminated and syntactically invalid.
> 
> Our sample above could thus be written as:
> 
> let xml = "
>   "
>   " 
>   " \(author)
>   " 
>   ""
> 
> If the second or subsequent lines had not begun with a quotation mark, or the 
> trailing quotation mark after the tag had not been included, Swift 
> would have emitted an error.
> 
> Rationale
> 
> This design is rather unusual, and it's worth pausing a moment to explain why 
> it has been chosen.
> 
> The traditional design for this feature, seen in languages like Perl and 
> Python, simply places one delimiter at the beginning of the literal and 
> another at the end. Individual lines in the literal

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Luis Henrique B. Sousa via swift-evolution]

Thanks Vladimir, your considerations and suggestions are totally valid, I'm
going to change the document accordingly.
Also as a non-native English speaker I think that other words could fit
better, such as 'tolerant' or 'permissive' -- but I dunno if they would
look great as a label. We will come up with the right keyword for it.

In relation to bad code, it could be a valid argument if my initial
proposal was under discussion instead, where the default 'fail fast'
behaviour would be "camouflaged" and bugs would be more difficult to catch.
In this new proposal we have such features explicitly defined, where the
user will be familiar with what it does and what results to expect for. I
don't see a way that it could drive to bad written code.

- Luis

On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S  wrote:

> I support this proposal. Probably we all should select the best labels
> (truncate/lenient or other). As not native English speaker, I don't feel
> like 'lenient' is well-known word or often-used word in software
> development. But all this just a details we need to discuss.
>
> What I think could be improved - is a motivation section. IMO the main
> purpose of proposed features is not to "eliminate the need for validations,
> reduce the number of fatal errors in runtime" but to allow us to have more
> clean code when *such validations just don't required*, when we just *don't
> care* about details.
> I.e. in situations, when we'll use [max(-1, a.startIndex) ..< min(5,
> a.endIndex)] and bounds checking manually to have the same result as in
> proposed subscripts.
>
> I.e. it is just a very handy addition to standard methods for collections,
> just like we can get first element by index but we have handy property
> '.first' for this purpose. Btw, it does not raise error, but returns T?. I
> think you can add notes regarding analogues with .first / .last
> properties(and probably with other) in proposal text.
>
> Someone can argue, that by using these subscripts, coders can write 'bad'
> code - but I can't accept such an argument - 'bad' coders already can write
> 'bad' code with other features of Swift and at the end they can implement
> these subscripts in their project and write 'bad' code. Should we stop to
> introduce handy and explicit feature for 'good' coders because of this?
>
> On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:
>
>> As we have discussed throughout this thread, the initial proposal was
>> modified to include alternative subscript methods instead of modifying the
>> default operator/subscript behaviour.
>> The first draft is
>> here:
>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>>
>> I've also put this as a gist so that you can leave comments with respect
>> to
>> the proposal document itself. Any suggestion or help is very welcome.
>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
>>
>> Regards,
>>
>> - Luis
>>
>> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa <
>> lshso...@gmail.com
>> > wrote:
>>
>> This proposal seeks to provide a safer ..< (aka half-open range
>> operator) in order to avoid **Array index out of range** errors in
>> execution time.
>>
>> Here is my first draft for this proposal:
>>
>> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
>>
>> In short, doing that in Swift causes a runtime error:
>>
>> leta =[1,2,3]
>> letb =a[0..<5]
>> print(b)
>>
>> > Error running code:
>> > fatal error: Array index out of range
>>
>> The proposed solution is to slice the array returning all elements
>> that
>> are below the half-open operator, even though the number of elements
>> is
>> lesser than the ending of the half-open operator. So the example above
>> would return [1,2,3].
>> We can see this very behaviour in other languages, such as Python and
>> Ruby as shown in the proposal draft.
>>
>> This would eliminate the need for verifications on the array size
>> before slicing it -- and consequently runtime errors in cases when the
>> programmer didn't.
>>
>> Viewing that it is my very first proposal, any feedback will be
>> helpful.
>>
>> Thanks!
>>
>> Luis Henrique Borges
>> @luishborges
>>
>>
>>
>>
>> ___
>> 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] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, Pyry Jahkola  wrote:

> I would really like a different name for scan. While it’s the term of art
> for Haskell and co, it really seems meaningless to regular programmers 
> (why
> is “scanning” the way you produce an array of intermediate reduces?), and 
> it
> would be better to follow the pattern already established elsewhere in the
> library to give friendlier names e.g. flatMap instead of bind, reduce
> instead of fold.
>
> I think Python calls it accumulate:
> http://docs.python.org/3/library/itertools.html#itertools.accumulate
>
> FWIW, Clojure calls it `reductions` which aligns pretty nicely with the 
> `reduce
> ` counterpart.

That's cute.

> I also think it would be nice for both scan and reduce to have overloads
> that take the first value as the initial (and return an optional) but 
> that’s
> probably a separate proposal.
>
> +1
>
> — Pyry
>
> ___
> 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] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Dave Abrahams via swift-evolution]

FWIW, I'm posting this review on behalf of Dmitri Gribenko, and Maxim
Moiseev, and me:

on Thu Apr 28 2016, Chris Lattner  wrote:

> Hello Swift community,
>
> The review of "SE-0045: Add scan, prefix(while:), drop(while:), and
> iterate to the stdlib" begins now and runs through May 3. The proposal
> is available here:
>
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>
>   * What is your evaluation of the proposal?

We like the bones, but we have some issues with the proposal as
submitted:

1. The proposal should be revised to account for language and standard
   library changes, most notably, the first argument label rules and API
   names have been overhauled since the proposal was written.  There are
   still many occurrences of obsolete names such as `SequenceType`.

   One good way to get there is to make the APIs compile (with
   `fatalError()` in method bodies if necessary) against the master
   branch in GitHub.  I realize it's been a long time since it was
   originally submitted, but it's really hard to evaluate a proposal if
   we'd have to change the APIs before they could even be incorporated
   into the codebase.

   The fact that names are out of date also casts doubt upon whether a
   first argument label is being proposed or not.  IMO it's really
   crucial that the proposal be revised this way *before* it is accepted.

2. In the “Detailed design” section it would have helped to have an
   explanation of the remark about “matching expected behavior.” We were
   scratching our heads over this one until we figured out it’s about
   the policy of not making multiple passes using a user-defined closure
   without an explicit appearance of `.lazy`.

3. We would prefer that `scan`’s first argument label was changed from
   `initial` to `startingWith`, and we would like to update `reduce` to
   use the same argument label. Whatever we do, `reduce` and `scan`
   should be consistent in this respect.

4. We find the name `iterate` problematic, in part because it is an
   active verb on a non-mutating method, but also because to us, it
   strongly implies eager evaluation.  In lieu of `iterate`, we'd prefer
   to see two overloads of `unfold` as shown below.  Although `unfold`
   is also an active verb, it is very much the correct term of art for
   the more general method and it allows us to establish the semantic
   relationship between the single- and two-argument forms.

func unfold(
  _ initialState: State, 
  applying nextElementAndState: (State)->(T, State)?
) -> UnfoldSequence

func unfold(
  _ initialElement: T, applying nextElement: (T)->T?
) -> UnfoldSequence

The second overload returns, approximately, 

  unfold(initialElement) { state in nextElement(state).map { (state, $0) } }

though that implementation would be a bit more eager than necessary; a
fully-lazy implementation is at
https://github.com/apple/swift-evolution/pull/195#issuecomment-214927063

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

Yes, it is crucial that Swift have a complete vocabulary of high-level
algorithms.  While these are simple, they are also fundamental missing
pieces.

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

Yes.

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

We don't have anything to say as a group about this, but Max or Dmitri
may have individual feedback.

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

An in-depth, collaborative, 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

-- 
Dave, Dmitri, and Maxim

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

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[David Sweeris via swift-evolution]

In your example, other types would still be able to conform to Delegate, by 
referencing it as "MyController.Delegate”, right? If so, I’m +1.

I’d imagine that it might also simplify the compiler a bit if we got rid of 
restrictions on where nested types are allowed to be declared.

- Dave Sweeris

> On Apr 28, 2016, at 12:15 PM, Brad Hilton via swift-evolution 
>  wrote:
> 
> Type nesting allows some convenient and straightforward semantics that we see 
> inside the Swift standard library such as views on String like 
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol 
> cannot be nested in a type and gives a non-obvious error that the 
> “Declaration is only valid at file scope.” Just as other nested types allow 
> proper contextual scoping, a nested protocol could make a lot sense for a 
> number of patterns. For example, there are many “Delegate” protocols 
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern before 
> and after type nesting:
> 
> // Without type nesting
> 
> protocol MyControllerDelegate : class {
> 
> }
> 
> class MyController {
> 
> weak var delegate: MyControllerDelegate?
> 
> }
> 
> // With type nesting
> 
> class MyController {
> 
> weak var delegate: Delegate?
> 
> protocol Delegate : class {
> 
> }
> 
> }
> 
> Though the change is mostly semantics, it does allow an explicit association 
> between My Controller and the Delegate instead of only a named association. 
> It also cleans up the module name space like other nested types and makes 
> associated protocols more discoverable in my opinion. 
> 
> I’d love to hear everyone’s thoughts.
> 
> Brad Hilton
> ___
> 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] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> Awesome.  Some specific suggestions below, but feel free to iterate in a pull 
> request if you prefer that.

I've adopted these suggestions in some form, though I also ended up rewriting 
the explanation of why the feature was designed as it is and fusing it with 
material from "Alternatives considered".

(Still not sure who I should list as a co-author. I'm currently thinking John, 
Tyler, and maybe Chris? Who's supposed to go there?)

Multiline string literals

Proposal: SE- 

Author(s): Brent Royal-Gordon 
Status: Second Draft
Review manager: TBD
 
Introduction

In Swift 2.2, the only means to insert a newline into a string literal is the 
\n escape. String literals specified in this way are generally ugly and 
unreadable. We propose a multiline string feature inspired by English 
punctuation which is a straightforward extension of our existing string 
literals.

This proposal is one step in a larger plan to improve how string literals 
address various challenging use cases. It is not meant to solve all problems 
with escaping, nor to serve all use cases involving very long string literals. 
See the "Future directions for string literals in general" section for a sketch 
of the problems we ultimately want to address and some ideas of how we might do 
so.

Swift-evolution threads: multi-line string literals. (April) 
,
 multi-line string literals (December) 

 
Draft
 Notes

Removes the comment feature, which was felt to be an unnecessary complication. 
This and the backslash feature have been listed as future directions. 

Loosens the specification of diagnostics, suggesting instead of requiring 
fix-its.

Splits a "Rationale" section out of the "Proposed solution" section.

Adds extensive discussion of other features which wold combine with this one.

I've listed only myself as an author because I don't want to put anyone else's 
name to a document they haven't seen, but there are others who deserve to be 
listed (John Holdsworth at least). Let me know if you think you should be 
included.

 
Motivation

As Swift begins to move into roles beyond app development, code which needs to 
generate text becomes a more important use case. Consider, for instance, 
generating even a small XML string:

let xml = "\n\n\t\n\t\t\(author)\n\t\n"
The string is practically unreadable, its structure drowned in escapes and 
run-together lines; it looks like little more than line noise. We can improve 
its readability somewhat by concatenating separate strings for each line and 
using real tabs instead of \t escapes:

let xml = "\n" + 
  "\n" + 
  " \n" + 
  " \(author)\n" + 
  " \n" + 
  ""
However, this creates a more complex expression for the type checker, and 
there's still far more punctuation than ought to be necessary. If the most 
important goal of Swift is making code readable, this kind of code falls far 
short of that goal.

 
Proposed
 solution

We propose that, when Swift is parsing a string literal, if it reaches the end 
of the line without encountering an end quote, it should look at the next line. 
If it sees a quote at the beginning (a "continuation quote"), the string 
literal contains a newline and then continues on that line. Otherwise, the 
string literal is unterminated and syntactically invalid.

Our sample above could thus be written as:

let xml = "
  "
  " 
  " \(author)
  " 
  ""
If the second or subsequent lines had not begun with a quotation mark, or the 
trailing quotation mark after the tag had not been included, Swift 
would have emitted an error.

 
Rationale

This design is rather unusual, and it's worth pausing a moment to explain why 
it has been chosen.

The traditional design for this feature, seen in languages like Perl and 
Python, simply places one delimiter at the beginning of the literal and another 
at the end. Individual lines in the literal are not marked in any way. 

We think continuation quotes offer several important advantages over the 
traditional design:

They help the compiler pinpoint errors in string literal delimiting. 
Traditional multiline strings have a serious weakness: if you forget the 
closing quote, the compiler has no idea where you wanted the literal to end. It 
simply continues on until the compiler 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Pyry Jahkola via swift-evolution]

> I would really like a different name for scan. While it’s the term of art for 
> Haskell and co, it really seems meaningless to regular programmers (why is 
> “scanning” the way you produce an array of intermediate reduces?), and it 
> would be better to follow the pattern already established elsewhere in the 
> library to give friendlier names e.g. flatMap instead of bind, reduce instead 
> of fold.
> 
> I think Python calls it accumulate: 
> http://docs.python.org/3/library/itertools.html#itertools.accumulate 
> 

FWIW, Clojure calls it `reductions 
`
 which aligns pretty nicely with the `reduce` counterpart.

> I also think it would be nice for both scan and reduce to have overloads that 
> take the first value as the initial (and return an optional) but that’s 
> probably a separate proposal.

+1

— Pyry

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

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, "pyry.jahkola--- via swift-evolution" 
 wrote:

> On 28 Apr 2016, Dave Abrahams wrote:
>
> I think I can guess what you wanted the above to mean but, mind you, 
> the
> in-place sort returns `()` so you wouldn't chain its result like that.
> On the
> other hand, the above code already works using the non-mutating 
> `.sort()
> ` (to be
> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the
> compiler
> probably optimises the copy away using copy-on-write anyway.
>
> No, the compiler can't automatically turn non-mutating operations into
> in-place operations.
>
> I'm talking about `.sorted()` in particular. Its implementation is essentially
> this:
>
> var result = ContiguousArray(self) // What if `self` is not used after this
> line?
> result.sort()
> return Array(result)
>
> Depending on what `self ` is and how copy-on-write works, if `foo().sorted()`
> was called on a temporary (unique) Array returned by `foo()`, I believe the
> initialisation `ContiguousArray(self)` could be able to reuse `self._buffer`
> instead of making a copy. 

Yes, *if* `self` was a contiguous array, there will be no copy in that
line, and *if* ARC can determine that `self` is not used after `result`
is constructed, then `result` will have a unique reference to the same
buffer and `result.sort()` can avoid doing a copy before mutating the
result.

> Whether it indeed does that, remains unclear to me, probably not.

It's worth doing an experiment; it might well work.  And if it doesn't,
someone should file a bug report :-)

-- 
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-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Chris Lattner via swift-evolution]

I’m passing on some feedback from a contributor who preferred to remain 
anonymous / offlist and emailed the review manager.  These are not my personal 
comments:

On Apr 28, 2016, at 11:11 AM, Chris Lattner  wrote:
> Proposal:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
> 

I would really like a different name for scan. While it’s the term of art for 
Haskell and co, it really seems meaningless to regular programmers (why is 
“scanning” the way you produce an array of intermediate reduces?), and it would 
be better to follow the pattern already established elsewhere in the library to 
give friendlier names e.g. flatMap instead of bind, reduce instead of fold.

I think Python calls it accumulate: 
http://docs.python.org/3/library/itertools.html#itertools.accumulate

While this isn’t great either, because you can think of reduce as 
“accumulating” a value, I still think it’ll be easy for people to understand 
the difference and remember which is which (since reducing sounds like boiling 
down, accumulating more like gathering multiple things and sounds similar to 
“cumulative”).

I also think it would be nice for both scan and reduce to have overloads that 
take the first value as the initial (and return an optional) but that’s 
probably a separate proposal.

Other than that, I think these will all make very useful additions to the 
library.


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

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, Jeff Hajewski  wrote:

> Thanks for bringing this back into the spotlight Pyry. A few of us have been
> working on this issue here:
>
> https://github.com/lorenzoracca/Swift-binary-search
>
> However we have sort of stalled as we have been unable to come up with a unary
> approach that Dave suggested using just Bool return values. And of course, as
> you say, the three case order enum would make this a trivial problem.
>
> I guess the question is, do we move forward without a unary implementation and
> update if/when we get a three case Order enum or do we wait on a three case
> Order enum and implement a fully generic version once?

Or you could just do it like this (Swift 2.2-compatible).  Am I missing
something?

extension CollectionType {
  /// Returns the index of the first element satisfying `predicate`,
  /// or `endIndex` if no such element exists.
  ///
  /// - Requires: `self` is partitioned with respect to `predicate`; 
  ///   that is, there exists an index `i` in `startIndex...endIndex`
  ///   such that `predicate` returns `false` for every element of
  ///   `self[startIndex..Bool
  ) -> Index {
var len = count
var min = startIndex
while len > 0 {
  let half = len/2
  let middle = min.advancedBy(half)
  
  if !predicate(self[middle]) {
min = middle.successor()
len -= half.successor()
  } else {
len = half
  }
}
return min
  }
}

extension CollectionType where Generator.Element : Comparable {
  /// Returns the index of the first element greater than or equal to
  /// `target`, or `endIndex` if no such element exists.
  ///
  /// - Requires: `self` is sorted.
  @warn_unused_result
  public func lowerBound(target: Self.Generator.Element) -> Index {
return binarySearch { $0 >= target }
  }
  
  /// Returns the index of the first element greater than
  /// `target`, or `endIndex` if no such element exists.
  ///
  /// - Requires: `self` is sorted.
  @warn_unused_result
  public func upperBound(target: Self.Generator.Element) -> Index {
return binarySearch { $0 > target }
  }
}

//===--- TEST IT --===//
import Darwin
for _ in 0..<1000 {
  // build a sorted array of up to 30 values in the range 0..<10
  var a : Array = []
  for _ in 0..= 0)
assert(u <= a.count)
assert(l <= u)
if l > 0 {
  assert(a[l - 1] < i)
}
if l < a.count {
  assert(a[l] >= i)
}
if u > 0 {
  assert(a[u - 1] <= i)
}
if u < a.count {
  assert(a[u] > i)
}
  }
}

-- 
Dave

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

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

[Josh Parmenter via swift-evolution]

I think this is a nice suggestion as well.
Best,
Josh

On Apr 28, 2016, at 1:52 PM, Joe Groff via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:


On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:

We all know and love sizeof(), but given that it's different from its C 
counterpart anyway, shouldn't these conform to Swift naming guidelines? In 
other words, after SE-0006, shouldn't these names be as follows?

```
size(of: T.Type)
size(ofValue: T)
stride(of: T.Type)
stride(ofValue: T)
align(of: T.Type)
align(ofValue: T)
```

There are obvious issues with two different things named `stride`, but IMO 
that's best addressed by renaming one of them; the real problem is that the 
word stride is used in two different ways already. Thoughts?

Seems reasonable to me.

-Joe

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



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD

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

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

[Joe Groff via swift-evolution]

> On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> We all know and love sizeof(), but given that it's different from its C 
> counterpart anyway, shouldn't these conform to Swift naming guidelines? In 
> other words, after SE-0006, shouldn't these names be as follows?
> 
> ```
> size(of: T.Type)
> size(ofValue: T)
> stride(of: T.Type)
> stride(ofValue: T)
> align(of: T.Type)
> align(ofValue: T)
> ```
> 
> There are obvious issues with two different things named `stride`, but IMO 
> that's best addressed by renaming one of them; the real problem is that the 
> word stride is used in two different ways already. Thoughts?

Seems reasonable to me.

-Joe

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Mark Lacey via swift-evolution]

I haven’t read through the complete proposal in detail, but regarding the 
‘scan’ operation I would like to point out that the definition given in the 
example matches the semantics of what is usually called ‘prescan' or 'exclusive 
scan', whereas ‘scan’ (aka ‘inclusive scan’ or ‘prefix sum’) would not include 
the identity element, and each position of the result would include applying 
the operator to the elements up to and including the element in the same 
position of the source array, e.g.:

  (1..<6).scan(combine: +) // [1, 3, 6, 10, 15, 21]

Sources:
  https://www.cs.cmu.edu/~guyb/papers/Ble93.pdf
  https://en.wikipedia.org/wiki/Prefix_sum

Mark


> On Apr 28, 2016, at 11:11 AM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0045: Add scan, prefix(while:), drop(while:), and iterate 
> to the stdlib" begins now and runs through May 3. The proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

[swift-evolution] [Pitch] Richer function identifiers, simpler function types

[Антон Жилин via swift-evolution]

Could you please publish it on Github? It is a bit difficult to read such
long posts in mailing lists.

1) I wouldn't like if ability to get function by name was removed.
Granted, it doesn't always work, but when it does, it's nice and concise.

2) SE-0066 and removal of tuple splat behaviour are caused by the fact that
Swift function argument lists are not tuples.
Inout, @noescape and others make sense only in function types.

Example:
(Int, Int) -> Int  will be a function that takes two Ints
((Int, Int)) -> Int  will be a function that takes one tuple
(((Int, Int))) -> Int  will be the same as ((Int, Int)) -> Int

3) Methods will be uncurried when used as closures.
Example:
[Int].map as ([Int], @noescape (Int) -> Int) -> [Int]

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Joe Groff via swift-evolution]

One thing I've been thinking about with regards to the existing `reduce` 
operation is whether it would be better expressed in Swift as taking its 
closure as (inout State, Element) -> Void rather than (State, Element) -> 
State. Doing so would avoid many of the accidentally-quadratic issues with the 
current formulation of reduce:

arrayOfArrays.reduce([], combine: +) // quadratic temporary arrays
arrayOfArrays.inPlaceReduce([], combine: +=) // can be linear by 
appending arrays in-place

Thanks to the scoped semantics of `inout`, there's no hazard of the mutable 
state reference being escaped, so the inout form is isomorphic to the 
traditional pure form of reduce.

Now `scan`-ing to generate an array of intermediate arrays is inherently 
quadratic, since each intermediate array shows up as a distinct copy in the 
resulting collection. However, if someone used `scan` to produce a sequence of 
tree data structures instead of flat arrays, it could still be interesting to 
share structure among the intermediate states collected by `scan` by performing 
an in-place operation to generate new values instead of an out-of-place 
operation. It might be interesting to consider a similar signature change to 
`scan` for these same reasons.

-Joe

> On Apr 28, 2016, at 11:11 AM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0045: Add scan, prefix(while:), drop(while:), and iterate 
> to the stdlib" begins now and runs through May 3. The proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md


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

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[pyry.jahkola--- via swift-evolution]

> On 28 Apr 2016, Dave Abrahams wrote:
> 
>> I think I can guess what you wanted the above to mean but, mind you, the
>> in-place sort returns `()` so you wouldn't chain its result like that. On the
>> other hand, the above code already works using the non-mutating `.sort()` 
>> (to be
>> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler
>> probably optimises the copy away using copy-on-write anyway.
> 
> No, the compiler can't automatically turn non-mutating operations into
> in-place operations.

I'm talking about `.sorted()` in particular. Its implementation 

 is essentially this:

var result = ContiguousArray(self) // What if `self` is not used after this 
line?
result.sort()
return Array(result)

Depending on what `self ` is and how copy-on-write works, if `foo().sorted()` 
was called on a temporary (unique) Array returned by `foo()`, I believe the 
initialisation `ContiguousArray(self)` could be able to reuse `self._buffer` 
instead of making a copy. Whether it indeed does that, remains unclear to me, 
probably not 
.

— Pyry

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

[swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

[Xiaodi Wu via swift-evolution]

We all know and love sizeof(), but given that it's different from its C
counterpart anyway, shouldn't these conform to Swift naming guidelines? In
other words, after SE-0006, shouldn't these names be as follows?

```
size(of: T.Type)
size(ofValue: T)
stride(of: T.Type)
stride(ofValue: T)
align(of: T.Type)
align(ofValue: T)
```

There are obvious issues with two different things named `stride`, but IMO
that's best addressed by renaming one of them; the real problem is that the
word stride is used in two different ways already. Thoughts?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, Pyry Jahkola  wrote:

> Good that you brought the topic of "fluent" interfaces up. I don't see any
> problem with explicit value type mutation and method chaining because fluent
> interfaces are constrained to reference types by the language. Details below:
>
> On 28 Apr 2016, at 03:44, Tyler Cloutier
>  wrote:
>
> How would this chain if I wanted to do something like:
>
> let median = foo.calculateBigHugeArray().sort().medianValue()
>
> and I want the sort to be done in place.
>
> I think I can guess what you wanted the above to mean but, mind you, the
> in-place sort returns `()` so you wouldn't chain its result like that. On the
> other hand, the above code already works using the non-mutating `.sort()` (to 
> be
> known as `.sorted()` in Swift 3), and—correct me if I'm wrong—the compiler
> probably optimises the copy away using copy-on-write anyway.

No, the compiler can't automatically turn non-mutating operations into
in-place operations.

-- 
Dave

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

Right, sorry, I should have clarified. The scenario to be supported here is
that the code for structs A, B, and C cannot be modified. They could be
part of the stdlib, for example, or a closed-source third-party library.


On Thu, Apr 28, 2016 at 1:18 PM, Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Apr 28, 2016, at 1:09 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry, that's not my question, which doesn't involve protocols I don't
> own. Let me restate. Given three types I don't own as follows:
>
> ```
> struct A : Frobnicate {
> override required func frobnicate() { print("A") } // "A", or delete
> to get default
> }
> struct B: Frobnicate {
> override required func frobnicate() { print("B") } // "B", or delete
> to get default
> }
> struct C: Frobnicate  { }
> ```
>
> We can't add the keywords if the structs are defined in a module we import
> but don't own.  We are only declaring the conformance retroactively.  The
> ability to do this is a crucial aspect of generic programming.  It isn't
> yet clear how your proposal handles retroactive modeling.
>
> -- E
>
>
> On Apr 28, 2016, at 11:48 AM, Xiaodi Wu  wrote:
>
> Sorry, that's not my question, which doesn't involve protocols I don't
> own. Let me restate. Given three types I don't own as follows:
>
> ```
> struct A {
> func frobnicate() { print("A") }
> }
> struct B {
> func frobnicate() { print("B") }
> }
> struct C { }
> ```
>
> I want to conform them to a protocol of my own design, Frobnicatable, and
> supply a default `frobnicate()`:
>
> ```
> protocol Frobnicatable {
> func frobnicate()
> }
> extension Frobnicatable {
> func frobnicate() { print("Default") }
> }
> extension A: Frobnicatable { }
> extension B: Frobnicatable { }
> extension C: Frobnicatable { }
>
> let c = C()
> c.frobnicate() // "Default"
> ```
>
> (Yes, I realize there are issues regarding static and dynamic dispatch
> that limit the utility of this particular example--let's leave those aside
> for now.)
> Where would I affix keywords such as `required` and `override` to make
> this work after implementation of your proposal?
>
>
> ___
> 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] [Review] SE-0017: Change Unmanaged to use UnsafePointer

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and 
runs through May 3. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

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] Requiring proactive overrides for default protocol implementations.

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 28, 2016, at 1:09 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Sorry, that's not my question, which doesn't involve protocols I don't own. 
> Let me restate. Given three types I don't own as follows:
> 
> ```
> struct A : Frobnicate {
> override required func frobnicate() { print("A") } // "A", or delete to 
> get default
> }
> struct B: Frobnicate {
> override required func frobnicate() { print("B") } // "B", or delete to 
> get default
> }
> struct C: Frobnicate  { }
> ```
> 
We can't add the keywords if the structs are defined in a module we import but 
don't own.  We are only declaring the conformance retroactively.  The ability 
to do this is a crucial aspect of generic programming.  It isn't yet clear how 
your proposal handles retroactive modeling.

> -- E
> 
> 
>> On Apr 28, 2016, at 11:48 AM, Xiaodi Wu  wrote:
>> 
>> Sorry, that's not my question, which doesn't involve protocols I don't own. 
>> Let me restate. Given three types I don't own as follows:
>> 
>> ```
>> struct A {
>> func frobnicate() { print("A") }
>> }
>> struct B {
>> func frobnicate() { print("B") }
>> }
>> struct C { }
>> ```
>> 
>> I want to conform them to a protocol of my own design, Frobnicatable, and 
>> supply a default `frobnicate()`:
>> 
>> ```
>> protocol Frobnicatable {
>> func frobnicate()
>> }
>> extension Frobnicatable {
>> func frobnicate() { print("Default") }
>> }
>> extension A: Frobnicatable { }
>> extension B: Frobnicatable { }
>> extension C: Frobnicatable { }
>> 
>> let c = C()
>> c.frobnicate() // "Default"
>> ```
>> 
>> (Yes, I realize there are issues regarding static and dynamic dispatch that 
>> limit the utility of this particular example--let's leave those aside for 
>> now.)
>> Where would I affix keywords such as `required` and `override` to make this 
>> work after implementation of your proposal?
> 
> ___
> 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-0017: Change Unmanaged to use UnsafePointer

[John McCall via swift-evolution]

> On Apr 28, 2016, at 11:10 AM, Chris Lattner via swift-evolution 
>  wrote:
> Hello Swift community,
> 
> The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and 
> runs through May 3. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md
> 

This is a really unfortunate proposal title.  I would suggest "Add conversions 
directly between Unmanaged and UnsafePointer".

John.

> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -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] [Review] SE-0052: Change IteratorType post-nil guarantee

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0052: Change IteratorType post-nil guarantee" begins now and 
runs through May 3. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager


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

[swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0045: Add scan, prefix(while:), drop(while:), and iterate to 
the stdlib" begins now and runs through May 3. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager


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

[swift-evolution] [Review] SE-0032: Add find method to SequenceType

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0032: Add find method to SequenceType" begins now and runs 
through May 3. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0032-sequencetype-find.md

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

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

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

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

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] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

Sorry, that's not my question, which doesn't involve protocols I don't own. Let 
me restate. Given three types I don't own as follows:

```
struct A : Frobnicate {
override required func frobnicate() { print("A") } // "A", or delete to get 
default
}
struct B: Frobnicate {
override required func frobnicate() { print("B") } // "B", or delete to get 
default
}
struct C: Frobnicate  { }
```

-- E


> On Apr 28, 2016, at 11:48 AM, Xiaodi Wu  wrote:
> 
> Sorry, that's not my question, which doesn't involve protocols I don't own. 
> Let me restate. Given three types I don't own as follows:
> 
> ```
> struct A {
> func frobnicate() { print("A") }
> }
> struct B {
> func frobnicate() { print("B") }
> }
> struct C { }
> ```
> 
> I want to conform them to a protocol of my own design, Frobnicatable, and 
> supply a default `frobnicate()`:
> 
> ```
> protocol Frobnicatable {
> func frobnicate()
> }
> extension Frobnicatable {
> func frobnicate() { print("Default") }
> }
> extension A: Frobnicatable { }
> extension B: Frobnicatable { }
> extension C: Frobnicatable { }
> 
> let c = C()
> c.frobnicate() // "Default"
> ```
> 
> (Yes, I realize there are issues regarding static and dynamic dispatch that 
> limit the utility of this particular example--let's leave those aside for 
> now.)
> Where would I affix keywords such as `required` and `override` to make this 
> work after implementation of your proposal?

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Matthew Johnson via swift-evolution]

I'm glad you brought this up and provided a clear example Xiaodi.

Erica, as I mentioned a few days ago (and Dave A gave +1) this proposal cannot 
break retroactive modeling if it is going to fly.  Can you please update it to 
clarify how you envision it interacts with retroactive modeling?  Would these 
new keywords only be required when the conformance is declared in the same 
module as the method? 

Sent from my iPad

> On Apr 28, 2016, at 12:48 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Apr 28, 2016 at 12:25 PM, Erica Sadun  wrote:
>> >
>> > On Apr 28, 2016, at 11:05 AM, Xiaodi Wu  wrote:
>> >
>> > How is retroactive modeling accommodated in this scheme? Say I want to 
>> > conform three types I don't own to a protocol of my design and supply a 
>> > default implementation for a protocol requirement. How would I go about it?
>> 
>> extension NotMyType: ProtocolIdesigned {...}
>> 
>> extension NotMyProtocol {
>>  required func method1() {...}
>>  override required func method2() {...} // assumes NMP has already 
>> provided default
>>  func newThing() {...}
>> }
>> 
>> The only tricky bit is when NotMyProtocol already has a default required 
>> func implementation and an override required func implementation (although 
>> that should be rare). In such case, you probably have to create a new 
>> protocol DerivedProtocol: NotMyProtocol and work from there. The override in 
>> the DerivedProtocol will then take priority over the override in 
>> NotMyProtocol.
> 
> Sorry, that's not my question, which doesn't involve protocols I don't own. 
> Let me restate. Given three types I don't own as follows:
> 
> ```
> struct A {
> func frobnicate() { print("A") }
> }
> struct B {
> func frobnicate() { print("B") }
> }
> struct C { }
> ```
> 
> I want to conform them to a protocol of my own design, Frobnicatable, and 
> supply a default `frobnicate()`:
> 
> ```
> protocol Frobnicatable {
> func frobnicate()
> }
> extension Frobnicatable {
> func frobnicate() { print("Default") }
> }
> extension A: Frobnicatable { }
> extension B: Frobnicatable { }
> extension C: Frobnicatable { }
> 
> let c = C()
> c.frobnicate() // "Default"
> ```
> 
> (Yes, I realize there are issues regarding static and dynamic dispatch that 
> limit the utility of this particular example--let's leave those aside for 
> now.)
> Where would I affix keywords such as `required` and `override` to make this 
> work after implementation of your proposal?
> 
> ___
> 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] Extending init checks for property initialization

[Vladimir.S via swift-evolution]

They *will* be initialized with nil. It's your business to fill any other 
value to them. So you do this in commonInitialization()
But again, I agree that such "defer init()" will be the best(IMO) solution 
here.


On 28.04.2016 20:27, Basem Emara wrote:

Good point about unwrapped optionals, but there's no compiler checks to make 
sure they get initialized.

The "defer init" solves the same problem that "defer" within functions 
resolved. There's no need to duplicate the function call in every init, or forget to call one as 
new initializers are added.


On Apr 28, 2016, at 12:50 PM, Vladimir.S  wrote:

I think I like this idea. It is clear that it is init() and 'defer' says that 
it is called at the end of each init. IMO we need exactly some kind of 'init' 
as only in init we can set un-initialized stored properties.

But, why implicitly unwrapped optionals are not solution here? I.e.

private var videoPlayer: AVPlayer!
private var videoPlayerLayer: AVPlayerLayer!



On 28.04.2016 19:04, Basem Emara via swift-evolution wrote:
I see what you’re saying and the forced optionals is pretty inconvenient.

As far as syntax, how about more of a “deferred” init that gets triggered 
regardless like this:

defer init() {
   // Always gets called no matter what designated init triggers
}


On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution 
 wrote:

Consider a relatively-common init pattern:

class SomeViewController: UIViewController {

  // MARK: Properties

  private var videoPlayer: AVPlayer
  private var videoPlayerLayer: AVPlayerLayer

  // MARK: - Object Lifecycle

  override init(nibName: String?, bundle nibBundle: NSBundle?) {
  super.init(nibName: nibName, bundle: nibBundle)

  commonInitialization()
  }

  required init?(coder decoder: NSCoder) {
  super.init(coder: decoder)

  commonInitialization()
  }

  private func commonInitialization() {
  videoPlayer = AVPlayer(...)
  videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
  }

}

This does not work. Both properties are non-optional, and the compiler 
complains that they are not initialized in either init method. It seems rather 
common to want a single point of contact regarding object initialization, 
regardless of the path taken to initialize that object. Ideally, objects could 
all be funneled to one designated initializer, but this isn’t always the case.

What are people’s thoughts about either a specialized function that is always 
called at the very end of each object’s lifecycle OR some sort of attribute for 
a function that hints that the compiler should follow it if called in an init 
function to check for property initialization?

func commonInit() {

}

or

@extend_init private func commonInitialization() {

}
___
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] [Pitch] Requiring proactive overrides for default protocol implementations.

[Vladimir.S via swift-evolution]

Erica,
In general I fully support this proposal. IMO Swift should be more explicit 
on what method in class/struct is required by protocol and if it overrides 
default implementation in protocol extension.


Actually, personally I like the idea that we need even separate base class 
inheritance declaration and protocol conformance like in Java:
class A:B implements C {..} or class A:B::C {}.. or even specify which 
protocol exactly requires this method like

func f() requiredBy SomeProto {} ...
but never mind :-)

Also your proposal should protect from such situations:
1. We use some 3rd party class AClass that implements AProtocol
2. We write extension to AProtocol, added new method ANewMethod
3. Then, we update the source of that AClass, and in new version of it the 
same ANewMethod was introduced(like in our AProtocol)
4. Now we have methods with same name in AClass and in protocol extension 
without any error/warning


Small fix(I think):
-
protocol A..
protocol B..
extension A { override required func foo() {...A extension...} }
Type CType: A, B {}
-
>>> don't you want to write just 'required' here, not 'override required' ?


Right now we have protocol extension's priority over type definition:

protocol A {}

class C:A {
func y() { print("Y in C") }
}

extension A { func y() {print("Y in A")} }

var c : A = C()
c.y() // Y in A here
---
so, it seems like you need to add this to "Impact on Existing Code"
I.e. now, when someone declared an protocol extension, it will get this 
method in class instance. Your proposal says we'll have class ext -> 
class-> protocol ex. -> protocol. Or I missed something?


Also, can't we just use 'override' instead of 'required'?
I.e. in protocol extension 'override' means - implements something, that 
was declared already in protocol. In class methods declaration 'override' 
will mean 'overrides base class'es implementation, or method in protocol 
extension, or implements protocol requirement'. I don't see the clear need 
of 'required' keyword here. I mean for me just 'override' will say 'this 
method is already declared somewhere'.


On 28.04.2016 19:53, Erica Sadun via swift-evolution wrote:

Draft. Criticism and suggestions both welcome. -- E


  Requiring Proactive Overrides for Default Protocol Implementations

  * Proposal: tbd
  * Author(s): Erica Sadun 
  * Status: tbd
  * Review manager: tbd



Introduction

This proposal enhances protocol implementation safety. It incorporates two
keywords that cooperate with compiler checks to limit "near miss"
implementation errors and accidental member overrides.

/This proposal was discussed on the Swift Evolution list in the [Pitch]
Requiring proactive overrides for default protocol implementations.
 thread/



Motivation

The proposal introduces a mandatory |required| keyword that marks members
as fulfiling protocol requirements. This expansion reduces the risk of
near-miss implementations (for example, adding |thud(x:
Double)| when |thud(x: Float)|is required), provides in-line documentation
of why the member has been included, thereby enhancing the code-level
documentation at the implementation point, and supports compile-time checks
for protocol conformance.

This proposal extends the |override| keyword to protocol conformance. The
Swift Programming Language describes the way subclass methods must override
implementations established in superclasses. /Methods on a subclass that
override the superclass’s implementation are marked with
*/|override|*/—overriding a method by accident, without override, is
detected by the compiler as an error. The compiler also detects methods
with override that don’t actually override any method in the superclass./

Adding an |override| requirement expands this cautious approach to
protocols. Developers must override implementations inherited from protocol
extensions with the |override| keyword. And the compiler will flag uses
of |override| where member implementations do not, in fact, override an
existing implementation. The keyword prevents accidental overrides, where a
sensible member name conflicts with signatures established in the protocol
conformance and forces users to proactively select a version in favor of
existing protocol extensions.



Detail
Design

  * The |override| keyword is extended to protocol inheritance, and when
used prefers the overridden behavior to the default behavior.
  * Swift will prefer an overridden implementation in preference in reverse
hierarchical order: type extensions take precedence over type
declarations over protocol extensions over protocol declarations
(assuming protocol

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

On Thu, Apr 28, 2016 at 12:25 PM, Erica Sadun  wrote:

> >
> > On Apr 28, 2016, at 11:05 AM, Xiaodi Wu  wrote:
> >
> > How is retroactive modeling accommodated in this scheme? Say I want to
> conform three types I don't own to a protocol of my design and supply a
> default implementation for a protocol requirement. How would I go about it?
>
> extension NotMyType: ProtocolIdesigned {...}
>
> extension NotMyProtocol {
>  required func method1() {...}
>  override required func method2() {...} // assumes NMP has already
> provided default
>  func newThing() {...}
> }
>
> The only tricky bit is when NotMyProtocol already has a default required
> func implementation and an override required func implementation (although
> that should be rare). In such case, you probably have to create a new
> protocol DerivedProtocol: NotMyProtocol and work from there. The override
> in the DerivedProtocol will then take priority over the override in
> NotMyProtocol.
>

Sorry, that's not my question, which doesn't involve protocols I don't own.
Let me restate. Given three types I don't own as follows:

```
struct A {
func frobnicate() { print("A") }
}
struct B {
func frobnicate() { print("B") }
}
struct C { }
```

I want to conform them to a protocol of my own design, Frobnicatable, and
supply a default `frobnicate()`:

```
protocol Frobnicatable {
func frobnicate()
}
extension Frobnicatable {
func frobnicate() { print("Default") }
}
extension A: Frobnicatable { }
extension B: Frobnicatable { }
extension C: Frobnicatable { }

let c = C()
c.frobnicate() // "Default"
```

(Yes, I realize there are issues regarding static and dynamic dispatch that
limit the utility of this particular example--let's leave those aside for
now.)
Where would I affix keywords such as `required` and `override` to make this
work after implementation of your proposal?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Extending init checks for property initialization

[Basem Emara via swift-evolution]

Good point about unwrapped optionals, but there's no compiler checks to make 
sure they get initialized.

The "defer init" solves the same problem that "defer" within functions 
resolved. There's no need to duplicate the function call in every init, or 
forget to call one as new initializers are added. 

> On Apr 28, 2016, at 12:50 PM, Vladimir.S  wrote:
> 
> I think I like this idea. It is clear that it is init() and 'defer' says that 
> it is called at the end of each init. IMO we need exactly some kind of 'init' 
> as only in init we can set un-initialized stored properties.
> 
> But, why implicitly unwrapped optionals are not solution here? I.e.
> 
> private var videoPlayer: AVPlayer!
> private var videoPlayerLayer: AVPlayerLayer!
> 
> 
>> On 28.04.2016 19:04, Basem Emara via swift-evolution wrote:
>> I see what you’re saying and the forced optionals is pretty inconvenient.
>> 
>> As far as syntax, how about more of a “deferred” init that gets triggered 
>> regardless like this:
>> 
>> defer init() {
>>// Always gets called no matter what designated init triggers
>> }
>> 
>>> On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution 
>>>  wrote:
>>> 
>>> Consider a relatively-common init pattern:
>>> 
>>> class SomeViewController: UIViewController {
>>> 
>>>   // MARK: Properties
>>> 
>>>   private var videoPlayer: AVPlayer
>>>   private var videoPlayerLayer: AVPlayerLayer
>>> 
>>>   // MARK: - Object Lifecycle
>>> 
>>>   override init(nibName: String?, bundle nibBundle: NSBundle?) {
>>>   super.init(nibName: nibName, bundle: nibBundle)
>>> 
>>>   commonInitialization()
>>>   }
>>> 
>>>   required init?(coder decoder: NSCoder) {
>>>   super.init(coder: decoder)
>>> 
>>>   commonInitialization()
>>>   }
>>> 
>>>   private func commonInitialization() {
>>>   videoPlayer = AVPlayer(...)
>>>   videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
>>>   }
>>> 
>>> }
>>> 
>>> This does not work. Both properties are non-optional, and the compiler 
>>> complains that they are not initialized in either init method. It seems 
>>> rather common to want a single point of contact regarding object 
>>> initialization, regardless of the path taken to initialize that object. 
>>> Ideally, objects could all be funneled to one designated initializer, but 
>>> this isn’t always the case.
>>> 
>>> What are people’s thoughts about either a specialized function that is 
>>> always called at the very end of each object’s lifecycle OR some sort of 
>>> attribute for a function that hints that the compiler should follow it if 
>>> called in an init function to check for property initialization?
>>> 
>>> func commonInit() {
>>> 
>>> }
>>> 
>>> or
>>> 
>>> @extend_init private func commonInitialization() {
>>> 
>>> }
>>> ___
>>> 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] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

> 
> On Apr 28, 2016, at 11:05 AM, Xiaodi Wu  wrote:
> 
> How is retroactive modeling accommodated in this scheme? Say I want to 
> conform three types I don't own to a protocol of my design and supply a 
> default implementation for a protocol requirement. How would I go about it?

extension NotMyType: ProtocolIdesigned {...}

extension NotMyProtocol {
 required func method1() {...}
 override required func method2() {...} // assumes NMP has already provided 
default
 func newThing() {...}
}

The only tricky bit is when NotMyProtocol already has a default required func 
implementation and an override required func implementation (although that 
should be rare). In such case, you probably have to create a new protocol 
DerivedProtocol: NotMyProtocol and work from there. The override in the 
DerivedProtocol will then take priority over the override in NotMyProtocol.

-- E

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

[swift-evolution] [Pitch] Allow nested protocol declarations

[Brad Hilton via swift-evolution]

Type nesting allows some convenient and straightforward semantics that we see 
inside the Swift standard library such as views on String like 
String.CharacterView, String.UnicodeScalarView, etc. However a protocol cannot 
be nested in a type and gives a non-obvious error that the “Declaration is only 
valid at file scope.” Just as other nested types allow proper contextual 
scoping, a nested protocol could make a lot sense for a number of patterns. For 
example, there are many “Delegate” protocols throughout the Cocoa frameworks. 
Here’s a controller/delegate pattern before and after type nesting:

// Without type nesting

protocol MyControllerDelegate : class {

}

class MyController {

weak var delegate: MyControllerDelegate?

}

// With type nesting

class MyController {

weak var delegate: Delegate?

protocol Delegate : class {

}

}

Though the change is mostly semantics, it does allow an explicit association 
between My Controller and the Delegate instead of only a named association. It 
also cleans up the module name space like other nested types and makes 
associated protocols more discoverable in my opinion. 

I’d love to hear everyone’s thoughts.

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

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu via swift-evolution]

How is retroactive modeling accommodated in this scheme? Say I want to
conform three types I don't own to a protocol of my design and supply a
default implementation for a protocol requirement. How would I go about it?
On Thu, Apr 28, 2016 at 11:53 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Draft. Criticism and suggestions both welcome. -- E
>
> Requiring Proactive Overrides for Default Protocol Implementations
>
>- Proposal: tbd
>- Author(s): Erica Sadun 
>- Status: tbd
>- Review manager: tbd
>
>
> 
> Introduction
>
> This proposal enhances protocol implementation safety. It incorporates two
> keywords that cooperate with compiler checks to limit "near miss"
> implementation errors and accidental member overrides.
>
> *This proposal was discussed on the Swift Evolution list in the [Pitch]
> Requiring proactive overrides for default protocol implementations.
>  thread*
> 
> Motivation
>
> The proposal introduces a mandatory required keyword that marks members
> as fulfiling protocol requirements. This expansion reduces the risk of
> near-miss implementations (for example, adding thud(x: Double) when thud(x:
> Float)is required), provides in-line documentation of why the member has
> been included, thereby enhancing the code-level documentation at the
> implementation point, and supports compile-time checks for protocol
> conformance.
>
> This proposal extends the override keyword to protocol conformance. The
> Swift Programming Language describes the way subclass methods must override
> implementations established in superclasses. *Methods on a subclass that
> override the superclass’s implementation are marked with 
> **override**—overriding
> a method by accident, without override, is detected by the compiler as an
> error. The compiler also detects methods with override that don’t actually
> override any method in the superclass.*
>
> Adding an override requirement expands this cautious approach to
> protocols. Developers must override implementations inherited from protocol
> extensions with the override keyword. And the compiler will flag uses of
> override where member implementations do not, in fact, override an
> existing implementation. The keyword prevents accidental overrides, where a
> sensible member name conflicts with signatures established in the protocol
> conformance and forces users to proactively select a version in favor of
> existing protocol extensions.
>
> Detail
> Design
>
>- The override keyword is extended to protocol inheritance, and when
>used prefers the overridden behavior to the default behavior.
>- Swift will prefer an overridden implementation in preference in
>reverse hierarchical order: type extensions take precedence over type
>declarations over protocol extensions over protocol declarations (assuming
>protocol declarations eventually adopt default implementations).
>- The required keyword marks a member as satisfying a protocol
>requirement, whether in protocol extensions, type declarations, or type
>extensions.
>
>
> Required
> Protocol Members
>
> Protocol requirements are marked with required for compile-time checks of
> intentional conformance.
>
> protocol A {
> func foo()
> func bar()
> func blort()
> func gar()
> }
> extension A {
> required func blort() {} // Correct, required by `A`
> func womble() {} // Correct, new method in extension
> func gar() {} // Incorrect: Compiler says: add `required` keyword or 
> remove implementation
> }
> struct B: A {
> required func foo() {} // Correct
> required func far() {} // Near miss. Compiler: rename method or drop 
> required keyword
> func bar() {} // Possible accidental name match. Compiler: rename method 
> or add required keyword
> }
>
>
> Member
> Overrides
>
> Overrides are marked with override to ensure intent.
>
> protocol A {
> func foo()
> func bar()
> func blort()
> func gar()
> }
> extension A {
> required func foo() {} // correct
> func womble() {} // correct
> }
> struct B: A {
> required func bar() {} // correct
> required func foo() {} // incorrect: Compiler says: add `override` 
> keyword or remove implementation
>  func womble() {} // incorrect: Compiler says add `override` keyword or 
> remove implementation. `required` is not needed as `womble` is not a required 
> protocol member.
> }
>
>
> 

Re: [swift-evolution] Extending init checks for property initialization

[Matthew Johnson via swift-evolution]

You may wish to have a look at my proposal for partial initializers.  It went 
dormant as I think everyone was burned out on talking about initializers at the 
time.  

https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md

Sent from my iPad

> On Apr 27, 2016, at 4:52 PM, Shannon Potter via swift-evolution 
>  wrote:
> 
> Consider a relatively-common init pattern:
> 
> class SomeViewController: UIViewController {
> 
>   // MARK: Properties
> 
>   private var videoPlayer: AVPlayer
>   private var videoPlayerLayer: AVPlayerLayer
> 
>   // MARK: - Object Lifecycle
> 
>   override init(nibName: String?, bundle nibBundle: NSBundle?) {
>   super.init(nibName: nibName, bundle: nibBundle)
> 
>   commonInitialization()
>   }
> 
>   required init?(coder decoder: NSCoder) {
>   super.init(coder: decoder)
> 
>   commonInitialization()
>   }
> 
>   private func commonInitialization() {
>   videoPlayer = AVPlayer(...)
>   videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
>   }
> 
> }
> 
> This does not work. Both properties are non-optional, and the compiler 
> complains that they are not initialized in either init method. It seems 
> rather common to want a single point of contact regarding object 
> initialization, regardless of the path taken to initialize that object. 
> Ideally, objects could all be funneled to one designated initializer, but 
> this isn’t always the case.
> 
> What are people’s thoughts about either a specialized function that is always 
> called at the very end of each object’s lifecycle OR some sort of attribute 
> for a function that hints that the compiler should follow it if called in an 
> init function to check for property initialization?
> 
> func commonInit() {
> 
> }
> 
> or
> 
> @extend_init private func commonInitialization() {
> 
> }
> ___
> 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] Requiring proactive overrides for default protocol implementations.

[Erica Sadun via swift-evolution]

Draft. Criticism and suggestions both welcome. -- E

Requiring Proactive Overrides for Default Protocol Implementations

Proposal: tbd
Author(s): Erica Sadun 
Status: tbd
Review manager: tbd
 
Introduction

This proposal enhances protocol implementation safety. It incorporates two 
keywords that cooperate with compiler checks to limit "near miss" 
implementation errors and accidental member overrides.

This proposal was discussed on the Swift Evolution list in the [Pitch] 
Requiring proactive overrides for default protocol implementations. 
 thread

 
Motivation

The proposal introduces a mandatory required keyword that marks members as 
fulfiling protocol requirements. This expansion reduces the risk of near-miss 
implementations (for example, adding thud(x: Double) when thud(x: Float)is 
required), provides in-line documentation of why the member has been included, 
thereby enhancing the code-level documentation at the implementation point, and 
supports compile-time checks for protocol conformance.

This proposal extends the override keyword to protocol conformance. The Swift 
Programming Language describes the way subclass methods must override 
implementations established in superclasses. Methods on a subclass that 
override the superclass’s implementation are marked with *override*—overriding 
a method by accident, without override, is detected by the compiler as an 
error. The compiler also detects methods with override that don’t actually 
override any method in the superclass.

Adding an override requirement expands this cautious approach to protocols. 
Developers must override implementations inherited from protocol extensions 
with the override keyword. And the compiler will flag uses of override where 
member implementations do not, in fact, override an existing implementation. 
The keyword prevents accidental overrides, where a sensible member name 
conflicts with signatures established in the protocol conformance and forces 
users to proactively select a version in favor of existing protocol extensions.

 
Detail
 Design

The override keyword is extended to protocol inheritance, and when used prefers 
the overridden behavior to the default behavior. 
Swift will prefer an overridden implementation in preference in reverse 
hierarchical order: type extensions take precedence over type declarations over 
protocol extensions over protocol declarations (assuming protocol declarations 
eventually adopt default implementations).
The required keyword marks a member as satisfying a protocol requirement, 
whether in protocol extensions, type declarations, or type extensions.
 
Required
 Protocol Members

Protocol requirements are marked with required for compile-time checks of 
intentional conformance.

protocol A { 
func foo() 
func bar()
func blort()
func gar()
}

extension A {
required func blort() {} // Correct, required by `A`
func womble() {} // Correct, new method in extension
func gar() {} // Incorrect: Compiler says: add `required` keyword or remove 
implementation
}

struct B: A {
required func foo() {} // Correct
required func far() {} // Near miss. Compiler: rename method or drop 
required keyword
func bar() {} // Possible accidental name match. Compiler: rename method or 
add required keyword
}
 
Member
 Overrides

Overrides are marked with override to ensure intent.

protocol A { 
func foo() 
func bar()
func blort()
func gar()
}

extension A {
required func foo() {} // correct
func womble() {} // correct
}

struct B: A {
required func bar() {} // correct
required func foo() {} // incorrect: Compiler says: add `override` keyword 
or remove implementation
 func womble() {} // incorrect: Compiler says add `override` keyword or 
remove implementation. `required` is not needed as `womble` is not a required 
protocol member.
}
 
Handling
 Changes

Default implementations can be added or removed at any time, as can type 
conformance implementations:

**Original****Change**  **Outcome**
Some member implemented in type Protocol adds that member   Must add 
`required` to type implementation or rename member to avoid conflict
Some member implemented in type, marked as `required`   Protocol removes that 
member or it never existedMust remove `required` from type 
implementation
Some member implemented in type, marked as `override`   Protocol exten

Re: [swift-evolution] Extending init checks for property initialization

[Vladimir.S via swift-evolution]

I think I like this idea. It is clear that it is init() and 'defer' says 
that it is called at the end of each init. IMO we need exactly some kind of 
'init' as only in init we can set un-initialized stored properties.


But, why implicitly unwrapped optionals are not solution here? I.e.

private var videoPlayer: AVPlayer!
private var videoPlayerLayer: AVPlayerLayer!


On 28.04.2016 19:04, Basem Emara via swift-evolution wrote:

I see what you’re saying and the forced optionals is pretty inconvenient.

As far as syntax, how about more of a “deferred” init that gets triggered 
regardless like this:

defer init() {
// Always gets called no matter what designated init triggers
}


On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution 
 wrote:

Consider a relatively-common init pattern:

class SomeViewController: UIViewController {

   // MARK: Properties

   private var videoPlayer: AVPlayer
   private var videoPlayerLayer: AVPlayerLayer

   // MARK: - Object Lifecycle

   override init(nibName: String?, bundle nibBundle: NSBundle?) {
   super.init(nibName: nibName, bundle: nibBundle)

   commonInitialization()
   }

   required init?(coder decoder: NSCoder) {
   super.init(coder: decoder)

   commonInitialization()
   }

   private func commonInitialization() {
   videoPlayer = AVPlayer(...)
   videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
   }

}

This does not work. Both properties are non-optional, and the compiler 
complains that they are not initialized in either init method. It seems rather 
common to want a single point of contact regarding object initialization, 
regardless of the path taken to initialize that object. Ideally, objects could 
all be funneled to one designated initializer, but this isn’t always the case.

What are people’s thoughts about either a specialized function that is always 
called at the very end of each object’s lifecycle OR some sort of attribute for 
a function that hints that the compiler should follow it if called in an init 
function to check for property initialization?

func commonInit() {

}

or

@extend_init private func commonInitialization() {

}
___
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-0066: Standardize function type argument syntax to require parentheses

[Thorsten Seitz via swift-evolution]

> Am 28.04.2016 um 00:38 schrieb David Owens II :
> 
> You forgot that parentheses are required for labeled closures with type 
> information:
> 
> x.sorted { (x: Int, y: Int) in x > y }
> 
> You'd have to handle that case as well.

That’s a single tuple argument.


> x.sorted { x: Int, y: Int in x > y }

And that’s an argument list with two arguments.


> I think the above leads to potentially ambiguous parsing constructs. 

Why? The `in` should be unambiguously ending the argument list without parsing 
issues, shouldn’t it?

-Thorsten


> 
> Sent from my iPhone
> 
> On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution 
>>> mailto:swift-evolution@swift.org>>:
>>> 
>>> > But keep away from closure expressions, please! There is nothing ambiguous
>>> > there.
>>> 
>>> Really?
>> 
>> Ok, you got me there :-)
>> I have to clarify: no ambiguity if parentheses would be prohibited around 
>> parameter lists in closure expressions like I suggested. 
>> Furthermore the current implementation seems to do some auto-(un)splatting 
>> which should go away.
>> 
>>> 
>>> func z1(block: (Int,Int) -> Void) {
>>>block(1,2)
>>> }
>>> 
>>> z1 { x, y in print(x,y)} //
>> 
>> (Int, Int) is a parameter list, so this is ok
>> 
>>> z1 { x in print(x.0, x.1)} // ???
>> 
>> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) 
>> is a parameter list and not a tuple.
>> Seems to be tuple unsplatting at work here.
>> 
>>> z1 { (x, y) in print(x, y)} //
>> 
>> This should not work for the given definition of z1 as (x, y) is a tuple.
>> 
>>> func z2(block: ((Int,Int)) -> Void) {
>>>block((1,2))
>>> }
>>> 
>>> z2 { x, y in print(x,y)} // ???
>> 
>> This should not work IMO (tuple splatting at work here)
>> 
>>> z2 { x in print(x.0, x.1)}
>> 
>> Fine, as x is a tuple.
>> 
>>> z2 { (x, y) in print(x, y)} // ???
>> 
>> Fine, as (x, y) is a tuple. This raises another issue, though: this is using 
>> pattern matching without having to write `let` or `case let`. That’s 
>> probably a good thing and I’d rather like to get rid of `let` for bindings 
>> in pattern matching in other places.
>> 
>>> //z2 { ((x, y)) in print(x, y)}  // compilation error
>> 
>> This should not work IMO as parentheses should not be allowed around 
>> argument lists in closure expressions.
>> 
>>> 
>>> // this will compile, but
>>> runtime error
>>> let ft : (Int,Int) -> Void = { x in print(x)} // hm..
>>> ft(1, 2)
>> 
>> There is no runtime error in my playground.
>> The result printed is (1, 2)
>> 
>> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) 
>> is a parameter list and not a tuple.
>> You would have to write
>> let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
>> or
>> let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)
>> 
>> 
>> To rehash:
>> 
>> Rules for function type definitions:
>> - parentheses are required around argument lists of more than one argument, 
>> i.e. (Int, Int) -> Void (same as in SE-0066)
>> - parentheses are required around argument lists with a single tuple 
>> argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
>> - parentheses are prohibited around single non-tuple arguments, i.e. Int -> 
>> Void (different from SE-0066)
>> 
>> Rule for argument lists in closure expressions:
>> - parentheses are prohibited around the argument list (as it is clearly 
>> enclosed by `{ … in`, therefore parentheses can only be used for tuples 
>> (different from current state)
>> 
>> This would result in nice unambiguous code without unnecessary parentheses.
>> 
>> -Thorsten
>> 
>> 
>>> 
>>> On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:
 I am strictly against requiring parentheses in closure expressions.
 Parentheses are visual clutter if not really needed and for a closure
 expression there is no need for parentheses as the parameter list is
 already nicely bracketed by `{ ... in`.
 Actually I would argue that parentheses around parameter lists in closure
 expressions should be prohibited for that reason.
 
 I'm not fond of requiring parentheses around single non-tuple parameters in
 type declarations either but I could probably grudgingly live with that 
 change.
 But keep away from closure expressions, please! There is nothing ambiguous
 there.
 
 -Thorsten
 
 
 Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution
 mailto:swift-evolution@swift.org>>:
 
> 
>> On Apr 26, 2016, at 1:31 PM, Chris Lattner > 
>> >> wrote:
>> 
>> 
>>> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution
>>> mailto:swift-evolution@swift.org> 
>>> >> 
>>> wrote:
>>

Re: [swift-evolution] Extending init checks for property initialization

[Basem Emara via swift-evolution]

I see what you’re saying and the forced optionals is pretty inconvenient.

As far as syntax, how about more of a “deferred” init that gets triggered 
regardless like this:

defer init() {
// Always gets called no matter what designated init triggers
}

> On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution 
>  wrote:
> 
> Consider a relatively-common init pattern:
> 
> class SomeViewController: UIViewController {
> 
>// MARK: Properties
> 
>private var videoPlayer: AVPlayer
>private var videoPlayerLayer: AVPlayerLayer
> 
>// MARK: - Object Lifecycle
> 
>override init(nibName: String?, bundle nibBundle: NSBundle?) {
>super.init(nibName: nibName, bundle: nibBundle)
> 
>commonInitialization()
>}
> 
>required init?(coder decoder: NSCoder) {
>super.init(coder: decoder)
> 
>commonInitialization()
>}
> 
>private func commonInitialization() {
>videoPlayer = AVPlayer(...)
>videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
>}
> 
> }
> 
> This does not work. Both properties are non-optional, and the compiler 
> complains that they are not initialized in either init method. It seems 
> rather common to want a single point of contact regarding object 
> initialization, regardless of the path taken to initialize that object. 
> Ideally, objects could all be funneled to one designated initializer, but 
> this isn’t always the case.
> 
> What are people’s thoughts about either a specialized function that is always 
> called at the very end of each object’s lifecycle OR some sort of attribute 
> for a function that hints that the compiler should follow it if called in an 
> init function to check for property initialization?
> 
> func commonInit() {
> 
> }
> 
> or
> 
> @extend_init private func commonInitialization() {
> 
> }
> ___
> 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] Extending init checks for property initialization

[Shannon Potter via swift-evolution]

Consider a relatively-common init pattern:

class SomeViewController: UIViewController {

// MARK: Properties

private var videoPlayer: AVPlayer
private var videoPlayerLayer: AVPlayerLayer

// MARK: - Object Lifecycle

override init(nibName: String?, bundle nibBundle: NSBundle?) {
super.init(nibName: nibName, bundle: nibBundle)

commonInitialization()
}

required init?(coder decoder: NSCoder) {
super.init(coder: decoder)

commonInitialization()
}

private func commonInitialization() {
videoPlayer = AVPlayer(...)
videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
}

}

This does not work. Both properties are non-optional, and the compiler 
complains that they are not initialized in either init method. It seems rather 
common to want a single point of contact regarding object initialization, 
regardless of the path taken to initialize that object. Ideally, objects could 
all be funneled to one designated initializer, but this isn’t always the case.

What are people’s thoughts about either a specialized function that is always 
called at the very end of each object’s lifecycle OR some sort of attribute for 
a function that hints that the compiler should follow it if called in an init 
function to check for property initialization?

func commonInit() {

}

or

@extend_init private func commonInitialization() {

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

[swift-evolution] Disallow arbitrary expressions in selectors

[Alex Hoppen via swift-evolution]

During the implementation of SE-0064 (Referencing Objective-C selector of 
property getters and setters) I have come across an issue that could be 
resolved my a minor change to the language and simplify the compiler a lot. I 
have drafted a proposal below.

Thoughts, comments, especially objections, appreciated.

– Alex

GitHub-Link: 
https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/-arbitrary-expressions-in-selectors.md
 


Disallow arbitrary expressions in selectors

Proposal: SE- 

Author(s): Alex Hoppen 
Status: Draft
Review manager: TBD
 
Introduction

It is currently possible to write arbitrary expressions inside #selector like 
the following: #selector(callThisFunc().bar). This complicates the 
implementation of proposals SE-0064 

 (Referencing Objective-C selector of property getters and setters) and SE-0062 

 (Referencing Objective-C key-paths) a lot. 

This proposal restricts expressions inside selectors to be a sequence of 
property or method refernces. I believe this will not be a major restrictions 
since arbitrary expressions in selectors are probably rarely used, have some 
rough edges and removing them would simplify the compiler.

 
Proposed
 solution

I propose allowed expressions inside #selector (and once implemented #keyPath) 
to be a series of instance or class members separated by . and allow 
disambiguating the last component using as.

 
Detailed
 design

 
Examples

class Address: NSObject {
  dynamic var street: String
  dynamic var town: String

  init(street: String, town: String) {
self.street = street
self.town = town
  }
}

class Person: NSObject {
  dynamic var name: String
  dynamic var homeAddress: Address

  func workAddress() -> Address {
// ...
  }

  func workAddress(formatter: AddressFormatter) -> String {
// ...
  }

  init(name: String, homeAddress: Address) {
self.name = name
self.homeAddress = homeAddress
  }
}

let me: Person = ...
The following examples will continue to work:

let _ = #selector(getter: Person.name)
let _ = #selector(getter: me.name)

let _ = #selector(getter: Person.homeAddress.street)
// Could also be written as
let _ = #selector(getter: Address.street)

let _ = #selector(Person.workAddress as () -> Address)
let _ = #selector(Person.workAddress(formatter: ))
I propose removing this kind of selector:

// Should produce selector "street". Note that the method workAddress() is 
never 
// called and its return type only used during type checking
let _ = #selector(getter: me.workAddress().street) 

// The above can be rewritten in a cleaner way like the following
let _ = #selector(getter: Address.street)
The proposed way to rewrite the selector elimininates potential confusion about 
the fact that calling a method inside #selector actually doesn't invoke it.

 
Grammar

selector → #selector(selector-modiferopt selector-path)

selector-modifier → getter:
selector-modifier → setter:

selector-path → type-identifier . selector-member-path as-disambiguationopt
selector-path → selector-member-path as-disambiguationopt

selector-member-path → identifier
selector-member-path → unqualified-name
selector-member-path → identifier . selector-member-path

as-disambiguation → as type-identifier
For a further rationale on why arbitrary expressions are no longer possible, 
see the discussion 

 on bugs.swift.org.

 
Impact
 on existing code

Code that currently uses this feature needs to be rewritten as described in the 
example above. I b

Re: [swift-evolution] SE-0066 Reaction

[Vladimir.S via swift-evolution]

Support your opinion on 100%. IMO Swift is language that has *elements* of 
FP that help us to build our software, but it was not born to be Pure FP 
language like Haskel https://en.wikipedia.org/wiki/Purely_functional
And I believe will never be, as then we should implement Haskell's I/O 
system in Swift and other 'features'.


Do we need Haskel instead of Swift? I don't believe so.

On 28.04.2016 16:48, Andrey Tarantsov via swift-evolution wrote:

Hey,

I'm inserting these opinions into almost every FP discussion, for which
I'm sorry, but I believe it's important to remind everyone that there's
the rest of us who will run away from Swift if it becomes too FP-y.


One of the things that I have noticed over the last year or so of
working with Swift is a trend in the community of libriaries being
written for Swift towards some of these "system semantics" (i.e.,
functional paradigms) like applicatives and such.


Just as an example of a different selection bias, I saw a couple of
those, digged in for a little bit and then ran far, far away. I haven't
seen any FP-related Swift libraries after that.

I absolutely don't have an impression that Swift has any affinity
towards being functional. To me, it embraces mutability and higher-level
object design aspects (like protocols) while taking only the bits of FP
that are actually useful (e.g. collection methods).

I don't have any data, but I can bet that most software developers on
iOS and Mac platforms welcome that, and don't really want the move
towards FP.

A.

___ 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] Requiring proactive overrides for default protocol implementations.

[Wallacy via swift-evolution]

I wrote a proposal few weeks ago about "Complete Composition Model" in
Swift, but still not finish (too many details)...

In my proposal, i thought about the problem in this topic. However after
thinking more generally, I found it best to solve in other direction:

- Every time one default protocol implementations is provide, the generated
Header will include de "default" at beginner.
-- No source code change, the change is just for generated header. For
Frameworks and libs, will apear em the "final generated header" of course.
But for changes in our own module, will apear on xcode generated header,
auto complete, detail tab, changes in color code, etc...

The ideia is provide a way to "see" more easily if a method has a default
implementation, but does not change de code itself because this
implementation can be made any time by someone, without break anything.

- Every time we "re implement" one default protocol implementation for
other module with already have this "default" keyword, we need to provide a
"implements" (or require) keyword to avoid a compiler warning.
-- Do not put a keyword to tell if you are implementing a protocol
requirement is not exactly a error, but can be considered if you previously
know about default implementation. No keyword is needed if no default
implementations is provided, but can be used for clarify the intention.

- For or own module, xcode / auto-complete, detail tab, color code, etc...
can tel you about the "has default implementation" without the warning.

At end of the day, there no need to any noise to tell something about
default implementation, just a little help.

If we make "everything explicit", inference type will be abolished.
Sometimes we can count on to develop "look the metadatas/interfaces"

If someone wants I can post the proposal I have written tomorrow.

Em qui, 28 de abr de 2016 às 02:08, Charles Srstka via swift-evolution <
swift-evolution@swift.org> escreveu:

> I would prefer the “override” only apply to methods that already had
> default protocol implementations, because then it could help avoid the
> mistake of overriding a default implementation that you didn’t realize was
> there, thinking that this was a method that you needed to supply.
>
> Charles
>
> On Apr 27, 2016, at 8:26 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> @Tod,
>
> This was a concern when Java changed the behaviour of `@Override`, but it
> didn't pan out. Everyone, even those with reservations, grew to like the
> new behaviour. I think the much improved error messages from the compiler
> helped, e.g.:
>
> protocol ViewObserver {
> func append(observer observer: Observer)
> func remove(observer observer: Observer)
> func removeAll()
> }
> struct AViewObserver: ViewObserver {
> func apend(observer observer: Observer) {
> ...
> }
> func remove(observer observer: Observer) {
> ...
> }
> func removeAll() {
> ...
> }
> }
>
> The only error you get at present with the above is that `AViewObserver`
> does not conform to `ViewObserver`, it doesn't tell you why. With the
> change the compiler would highlight that `apend` doesn't override `append`
> :(.
>
>
>   -- Howard.
>
> On 28 April 2016 at 11:17, Tod Cunningham 
> wrote:
>
>> I think it would be odd and confusing to always have to use override when
>> implementing protocol methods (especially protocol methods without default
>> implementations).   To me override is telling me that there is another
>> implementation, and I am for lack of a better word overriding that
>> implementation.   However, for a protocol w/o a default implementation,
>> there is no implementation.  You aren’t overriding anything.  You are just
>> conforming to a signature.  Now protocol’s with default implementations
>> there could be a case made for using override.  Expect Swift current
>> implementation doesn't really override the default implementation, as shown
>> in my example.  The other issues would be if I am overriding  something, I
>> would expect to be able to execute the default implementation from within
>> my override.
>>
>> It might be nice to have some syntax that would identify the protocol
>> that is being implemented at the point of the implementation. For example
>> (although I don't like this syntax):
>>func (protocolname1, protocolname2) commonmethod() -> Void { .. the
>> implementation.. }
>>
>> - Tod Cunningham
>> 
>> From: swift-evolution-boun...@swift.org <
>> swift-evolution-boun...@swift.org> on behalf of Josh Parmenter via
>> swift-evolution 
>> Sent: Wednesday, April 27, 2016 8:27 PM
>> To: Howard Lovatt
>> Cc: swift-evolution
>> Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for
>> default protocol implementations.
>>
>> On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution <
>> swift-evolution@swift.

Re: [swift-evolution] SE-0066 Reaction

[Gwendal Roué via swift-evolution]

> Hey, 
> 
> I'm inserting these opinions into almost every FP discussion, for which I'm 
> sorry, but I believe it's important to remind everyone that there's the rest 
> of us who will run away from Swift if it becomes too FP-y.
> 
>> One of the things that I have noticed over the last year or so of working 
>> with Swift is a trend in the community of libriaries being written for Swift 
>> towards some of these "system semantics" (i.e., functional paradigms) like 
>> applicatives and such.
> 
> Just as an example of a different selection bias, I saw a couple of those, 
> digged in for a little bit and then ran far, far away. I haven't seen any 
> FP-related Swift libraries after that.
> 
> I absolutely don't have an impression that Swift has any affinity towards 
> being functional. To me, it embraces mutability and higher-level object 
> design aspects (like protocols) while taking only the bits of FP that are 
> actually useful (e.g. collection methods).
> 
> I don't have any data, but I can bet that most software developers on iOS and 
> Mac platforms welcome that, and don't really want the move towards FP.
> 
> A.

What do you think of this message by Chris Lattner: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015774.html?

Gwendal

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

Re: [swift-evolution] SE-0066 Reaction

[Andrey Tarantsov via swift-evolution]

Hey, 

I'm inserting these opinions into almost every FP discussion, for which I'm 
sorry, but I believe it's important to remind everyone that there's the rest of 
us who will run away from Swift if it becomes too FP-y.

> One of the things that I have noticed over the last year or so of working 
> with Swift is a trend in the community of libriaries being written for Swift 
> towards some of these "system semantics" (i.e., functional paradigms) like 
> applicatives and such.

Just as an example of a different selection bias, I saw a couple of those, 
digged in for a little bit and then ran far, far away. I haven't seen any 
FP-related Swift libraries after that.

I absolutely don't have an impression that Swift has any affinity towards being 
functional. To me, it embraces mutability and higher-level object design 
aspects (like protocols) while taking only the bits of FP that are actually 
useful (e.g. collection methods).

I don't have any data, but I can bet that most software developers on iOS and 
Mac platforms welcome that, and don't really want the move towards FP.

A.

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Vladimir.S via swift-evolution]

I support this proposal. Probably we all should select the best labels 
(truncate/lenient or other). As not native English speaker, I don't feel 
like 'lenient' is well-known word or often-used word in software 
development. But all this just a details we need to discuss.


What I think could be improved - is a motivation section. IMO the main 
purpose of proposed features is not to "eliminate the need for validations, 
reduce the number of fatal errors in runtime" but to allow us to have more 
clean code when *such validations just don't required*, when we just *don't 
care* about details.
I.e. in situations, when we'll use [max(-1, a.startIndex) ..< min(5, 
a.endIndex)] and bounds checking manually to have the same result as in 
proposed subscripts.


I.e. it is just a very handy addition to standard methods for collections, 
just like we can get first element by index but we have handy property 
'.first' for this purpose. Btw, it does not raise error, but returns T?. I 
think you can add notes regarding analogues with .first / .last 
properties(and probably with other) in proposal text.


Someone can argue, that by using these subscripts, coders can write 'bad' 
code - but I can't accept such an argument - 'bad' coders already can write 
'bad' code with other features of Swift and at the end they can implement 
these subscripts in their project and write 'bad' code. Should we stop to 
introduce handy and explicit feature for 'good' coders because of this?


On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:

As we have discussed throughout this thread, the initial proposal was
modified to include alternative subscript methods instead of modifying the
default operator/subscript behaviour.
The first draft is
here: 
https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md

I've also put this as a gist so that you can leave comments with respect to
the proposal document itself. Any suggestion or help is very welcome.
https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8

Regards,

- Luis

On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa mailto:lshso...@gmail.com>> wrote:

This proposal seeks to provide a safer ..< (aka half-open range
operator) in order to avoid **Array index out of range** errors in
execution time.

Here is my first draft for this proposal:

https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md

In short, doing that in Swift causes a runtime error:

leta =[1,2,3]
letb =a[0..<5]
print(b)

> Error running code:
> fatal error: Array index out of range

The proposed solution is to slice the array returning all elements that
are below the half-open operator, even though the number of elements is
lesser than the ending of the half-open operator. So the example above
would return [1,2,3].
We can see this very behaviour in other languages, such as Python and
Ruby as shown in the proposal draft.

This would eliminate the need for verifications on the array size
before slicing it -- and consequently runtime errors in cases when the
programmer didn't.

Viewing that it is my very first proposal, any feedback will be helpful.

Thanks!

Luis Henrique Borges
@luishborges




___
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] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov via swift-evolution]

Let me bump this thread. How do we move forward?

Here's an interface of another Swift class I've just made (slowly rewriting my 
Obj-C components to Swift here):

public class SoloContainerViewController: UIViewController {

private var _contentViewController: UIViewController?

public var contentViewController: UIViewController?  // delegates to 
setContentViewController:animated:completion:

public init(contentViewController: UIViewController?) { ... }

public required init?(coder aDecoder: NSCoder) { ... }

public override func viewDidLoad() { ... }

public func setContentViewController(contentViewController: 
UIViewController?, animated: Bool, completion completionBlock: 
dispatch_block_t?) { ... }

public /*protected*/ func transition(fromView oldView: UIView?, toView 
newView: UIView?, animated: Bool, completion completionBlock: (finished: Bool) 
-> Void) { ... }

public /*protected*/ func 
willTransitionToContentViewController(newViewController: UIViewController?) { 
... }

public /*protected*/ func 
didTransitionFromContentViewController(oldViewController: UIViewController?) { 
... }

}

This is madness, we have to do SOMETHING!

This class is designed to be subclassed, with a bunch of hooks that subclasses 
may be interested in. Most of the reusable views and view controllers that I 
make look like this.

Even when I use delegates, I still forward delegate calls through overridable 
protected methods, based on my long history of subclassing UIScrollView (and 
other controls) and wishing that the subclass had access to the delegate 
methods.

Nobody outside of the class should be interested in those protected methods; 
they are not safe to call, they're override points.

And I often have to pick very telling method names, so that I don't end up 
accidentally calling one of those methods from outside. Sometimes that's fairly 
hard, like when there's a public save(), a private saveNow() and a protected 
saveContent().


Our best consensus the last time was:

>>> My point is that "protected" *isn't* access control. If we added it, it 
>>> would have to be as an independent modifier.
> 
> Okay. So you see it as “public subclassonly”, leaving space for “internal 
> subclassonly” (which makes sense, although not as important in practice).
> 
> I can agree with that, let's consider it a new strawman.


So how do we move forward?

A.

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