Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Rob Mayoff via swift-evolution]

>
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
> ...
> }
> ...
>

You need not duplicate the default logic:


private class DefaultDelegate: NSObject, UITableViewDelegate { }
private let defaultDelegate = DefaultDelegate()

public class UITableView {

private func addRow(at indexPath: NSIndexPath) {
...
cell.size.height = (delegate ?? defaultDelegate).tableView(self,
heightForRowAtIndexPath: indexPath)
...
}

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[T.J. Usiyan via swift-evolution]

-1
I hope that default implementations living in the protocol will address
this. I would even prefer to move in 'the other direction' and have
optional methods on protocols come into swift as default implementations.
TJ

On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > Protocol requirements with default (no-op) implementations already
> satisfy that design goal, no?
>
> Kind of. If I may steelman* optional members for a moment...
>
> In cases where a default implementation would do, the default
> implementation will usually also be the behavior you want for a nil
> instance, but there's no convenient way to share logic between the two. For
> example, consider this:
>
> protocol UITableViewDelegate {
> ...
> func tableView(_ tableView: UITableView,
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
> }
> extension UITableViewDelegate {
> func tableView(_ tableView: UITableView,
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
> return tableView.rowHeight
> }
> }
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
> ...
> }
> ...
>
> You have to duplicate the default logic both in the default implementation
> and at the call site, but there is no convenient way to share it—the
> extension method can't call into an expression at some call site, and
> contrarily the call site can't invoke the default logic from the extension.
>
> If the method were optional, then optional chaining would solve this
> problem for us:
>
> protocol UITableViewDelegate {
> ...
> optional func tableView(_ tableView: UITableView,
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
> }
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView?(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
> ...
> }
> ...
>
> This way, there is only one source of default behavior: the call site.
>
> I'm also concerned by the thought of just how many sub-protocols we might
> end up with. When I try to fully factor NSTableViewDelegate (as it
> currently exists in the headers), I end up with ten protocols:
>
> NSTableViewDelegate
> - tableView:willDisplayCell:forTableColumn:row:
>
> NSTableViewLayoutDelegate: NSTableViewDelegate
> - tableView:heightOfRow:
>
> NSTableViewRowSelectionDelegate: NSTableViewDelegate
> - tableView:shouldSelectRow:
> - selectionShouldChangeInTableView:
> - tableViewSelectionIsChanging:
> - tableViewSelectionDidChange:
> - tableView:shouldTrackCell:forTableColumn:row: (10.5)
> - tableView:selectionIndexesForProposedSelection: (10.5)
>
> NSTableViewTypeSelectDelegate: NSTableViewDelegate (10.5)
> - tableView:typeSelectStringForTableColumn:row:
> - tableView:nextTypeSelectMatchFromRow:toRow:forString:
> -
> tableView:shouldTypeSelectForEvent:withCurrentSearchString:
>
> NSTableViewToolTipDelegate: NSTableViewDelegate
> -
> tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:
>
> NSTableViewColumnDelegate: NSTableViewDelegate
> - tableView:shouldEditTableColumn:row:
> - tableView:shouldSelectTableColumn:
> - tableView:mouseDownInHeaderOfTableColumn:
> - tableView:didClickTableColumn:
> - tableView:didDragTableColumn:
> - tableViewColumnDidMove:
> - tableViewColumnDidResize:
> - tableView:sizeToFitWidthOfColumn: (10.6)
> - tableView:shouldReorderColumn:toColumn: (10.6)
>
> NSTableViewCellExpansionDelegate: NSTableViewDelegate (10.5)
> - tableView:shouldShowCellExpansionForTableColumn:row:
>
> NSTableViewCustomCellDelegate: NSTableViewDelegate (10.5)
> - tableView:dataCellForTableColumn:row:
> - tableView:isGroupRow:
>
> NSTableViewCellViewDelegate: NSTableViewDelegate (10.7)
> - tableView:viewForTableColumn:row:
>
> NSTableViewRowViewDelegate: NSTableViewDelegate (10.7)
> - tableView:rowViewForRow:
> - tableView:didAddRowView:forRow:
> - 

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Brent Royal-Gordon via swift-evolution]

> Protocol requirements with default (no-op) implementations already satisfy 
> that design goal, no?

Kind of. If I may steelman* optional members for a moment...

In cases where a default implementation would do, the default implementation 
will usually also be the behavior you want for a nil instance, but there's no 
convenient way to share logic between the two. For example, consider this:

protocol UITableViewDelegate {
...
func tableView(_ tableView: UITableView, 
heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
}
extension UITableViewDelegate {
func tableView(_ tableView: UITableView, 
heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
return tableView.rowHeight
}
}

class UITableView {
...
private func addRow(at indexPath: NSIndexPath) {
...
cell.size.height = delegate?.tableView(self, 
heightForRowAtIndexPath: indexPath) ?? rowHeight
...
}
...

You have to duplicate the default logic both in the default implementation and 
at the call site, but there is no convenient way to share it—the extension 
method can't call into an expression at some call site, and contrarily the call 
site can't invoke the default logic from the extension.

If the method were optional, then optional chaining would solve this problem 
for us:

protocol UITableViewDelegate {
...
optional func tableView(_ tableView: UITableView, 
heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
}

class UITableView {
...
private func addRow(at indexPath: NSIndexPath) {
...
cell.size.height = delegate?.tableView?(self, 
heightForRowAtIndexPath: indexPath) ?? rowHeight
...
}
...

This way, there is only one source of default behavior: the call site.

I'm also concerned by the thought of just how many sub-protocols we might end 
up with. When I try to fully factor NSTableViewDelegate (as it currently exists 
in the headers), I end up with ten protocols:

NSTableViewDelegate
- tableView:willDisplayCell:forTableColumn:row:

NSTableViewLayoutDelegate: NSTableViewDelegate
- tableView:heightOfRow:

NSTableViewRowSelectionDelegate: NSTableViewDelegate
- tableView:shouldSelectRow:
- selectionShouldChangeInTableView:
- tableViewSelectionIsChanging:
- tableViewSelectionDidChange:
- tableView:shouldTrackCell:forTableColumn:row: (10.5)
- tableView:selectionIndexesForProposedSelection: (10.5)

NSTableViewTypeSelectDelegate: NSTableViewDelegate (10.5)
- tableView:typeSelectStringForTableColumn:row:
- tableView:nextTypeSelectMatchFromRow:toRow:forString:
- tableView:shouldTypeSelectForEvent:withCurrentSearchString:

NSTableViewToolTipDelegate: NSTableViewDelegate
- tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:

NSTableViewColumnDelegate: NSTableViewDelegate
- tableView:shouldEditTableColumn:row:
- tableView:shouldSelectTableColumn:
- tableView:mouseDownInHeaderOfTableColumn:
- tableView:didClickTableColumn:
- tableView:didDragTableColumn:
- tableViewColumnDidMove:
- tableViewColumnDidResize:
- tableView:sizeToFitWidthOfColumn: (10.6)
- tableView:shouldReorderColumn:toColumn: (10.6)

NSTableViewCellExpansionDelegate: NSTableViewDelegate (10.5)
- tableView:shouldShowCellExpansionForTableColumn:row:

NSTableViewCustomCellDelegate: NSTableViewDelegate (10.5)
- tableView:dataCellForTableColumn:row:
- tableView:isGroupRow:

NSTableViewCellViewDelegate: NSTableViewDelegate (10.7)
- tableView:viewForTableColumn:row:

NSTableViewRowViewDelegate: NSTableViewDelegate (10.7)
- tableView:rowViewForRow:
- tableView:didAddRowView:forRow:
- tableView:didRemoveRowView:forRow:
- tableView:rowActionsForRow:edge: (10.11)

Some of these are probably unnecessary; they could be merged into 
NSTableViewDelegate and given default implementations. But at least a few of 
them would be very much needed. Would users be able to navigate this mess? 
Would they discover the features tucked away in sub-protocols? I'm just not 
sure.

And of course the safety issues that make optional protocol members dangerous 
in Objective-C don't exist in 

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Russ Bishop via swift-evolution]

>   * What is your evaluation of the proposal?

Generally I like the proposal and I think it helps solidify the bridging story.


On casting: In our coding standards, any use of “as!” warrants much higher 
scrutiny (any use of try! or IUOs gets the same treatment). For a type that 
opts-in to type discovery, why can’t “as?” casting work? It seems like there’s 
enough information to determine if the cast should succeed or not. 

It is also slightly strange that the collection types have the same problems 
but allow bridging, and in the as! case they actually defer checking until 
later. It may just be an inconsistency we have to live with for practical 
reasons.


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

Yes; the mountains of Objective-C code aren’t going away anytime soon.


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

It has some rough edges but I think they’re unavoidable given the fundamental 
differences between Objective-C and Swift generics.




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

Re: [swift-evolution] [Pitch] Custom Namespaces

[Howard Lovatt via swift-evolution]

Yes something in this space might be useful, but, and this is a significant
but, we do have modules and files to break code into. So it wouldn't be a
top priority.

On Wednesday, 30 March 2016, Niels Andriesse via swift-evolution <
swift-evolution@swift.org> wrote:

> At the moment, it's not possible to define custom namespaces. They can be
> emulated using static members on an enum:
>
> enum Foo {
>   static var bar: Bar
>   static func baz() { }
> }
>
> This is not ideal, because:
>
>- The case shown above is semantically speaking obviously not an enum and
>shouldn't be presented as such.
>- The members are required to be static unnecessarily.
>- Not all top-level declarations can be nested like this (e.g.
>protocols).
>- If we allow namespaces to be reused in different files within the
>same module, this could potentially be used as a custom scope for access
>control (e.g. using the proposed private(...) syntax, so in this case
>private(Foo)).
>
> Are there any plans to allow custom namespaces (for example as shown
> below)?
>
> namespace Foo {
>   var bar: Bar
>   func baz() { }
> }
>
> Alternatively, a similar situation could be achieved by introducing
> submodules.
>


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

Re: [swift-evolution] Feature proposal: Range operator with step

[Howard Lovatt via swift-evolution]

No I would not be surprised by a limit based on Int provided that:

  1. It was articulated in the documentation
  2. The error occurred when the Range/stride was created
  3. The error message stated that there were too many steps and what the
step limit was

What I don't think would be acceptable was if:

  1. The error occurred part way through the iteration; not at creation time
  2. There was no error and the loop turned into an infinite loop silently

On Friday, 1 April 2016, Xiaodi Wu  wrote:

> All true. I call that Erica's solution because her proposal is where I
> first found it sketched out.
>
> I'm not convinced that Erica's solution is definitely the right answer
> because:
>
> (a) Use of an iteration counter of type Int to stride through Doubles is
> an implementation detail which is not an obviously correct choice; users
> might find it surprising that how many steps they get for StrideTo
> is constrained by Int.max
>
> (b) I'm not completely certain that there is no use case for a loop with
> more than Int.max steps so long as you break before the end, so I'm not
> completely certain that an error right off the bat is the most ideal
> behavior; for example, someone may wish to increment by a user-supplied
> epsilon from one user-supplied value to another but break after a certain
> amount of time has elapsed
>
> (c) I agree with you that it's Swiftier to do nothing than to start
> returning approximately correct values, but in a scenario such as `for _ in
> stride(from: 0, to: DBL_MAX, by: someAbsurdlySmallValue) { }` it may not
> matter (I cannot imagine a use case for this ridiculous loop, but for the
> sake of argument here let's take it); one alternative solution someone
> might propose, for example, would be to fall back to the old
> error-accumulating algorithm after the iteration counter has reached its
> max possible value
>
> So I guess the feedback I'm interested in is:
>
> - Would you be surprised to find that Stride may become
> constrained by an upper limit in the number of steps?
>
> - If not, would it irk you that such a limit is based on the size of a
> totally unrelated numeric type (namely, Int) which is an implementation
> detail? Would you prefer that the limit be something related to the nature
> of the type itself (for example, a maximum number of steps for
> StrideTo that reflects the maximum exactly representable integer in
> a Double)?
>
> - If there is to be an upper limit on steps, would you prefer an error
> when the Stride is being initialized or when the iteration counter
> overflows?
>
> - Would you rather instead be able to stride indefinitely, as is currently
> the case in Swift 2, accepting that error will start accumulating at some
> point?
>
> On Thu, Mar 31, 2016 at 4:33 PM Howard Lovatt via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>> If you define a range as range[i] = first + i * stride where i is an Int
>> then this generates an error when there are more than Int_Max steps, see
>> code previously posted. The error is generated when the range is formed,
>> which is ideal since an error part way along an iteration or a never ending
>> iteration would be difficult to track down.
>>
>> On Friday, 1 April 2016, Stephen Canon via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>>
>>>
>>> > On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> > On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote:
>>> >>
>>> >> on Thu Mar 31 2016, Xiaodi Wu  wrote:
>>> >>
>>> >>> Thoughts on an edge case: so long as it's possible to use
>>> >>> `stride(from:to:by:)` with Double, we'll need to figure out what
>>> >>> happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.
>>> >>> Bounds may be unknown at compile time, obviously.
>>> >>>
>>> >>> Currently (this is by reasoning through the code, not actually
>>> >>> observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:
>>> >>> DBL_MIN) { }` degenerates into an infinite loop once you reach
>>> >>> sufficient large values such that `current + stride == current`,
>>> which
>>> >>> for a stride of DBL_MIN should happen pretty quickly.
>>> >>>
>>> >>> In Erica's proposed floating point Stride, an Int is used to count
>>> >>> iterations (and iterations need to be counted in order to avoid
>>> >>> accumulating error). Thus, one must break from `for i in stride(from:
>>> >>> 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter
>>> >>> overflows or it will trap. IMO, trapping at some point is fine, but I
>>> >>> think a limit of Int.max iterations might be rather arbitrary for a
>>> >>> StrideTo (or whatever it will be named) and I'm not sure how
>>> >>> one can justify why the behavior of StrideTo would change
>>> from
>>> >>> machine to machine based on the size of 

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Howard Lovatt via swift-evolution]

+1 with the same evaluation as Sebastian Hagedorn

On Friday, 1 April 2016, Sebastian Hagedorn via swift-evolution <
swift-evolution@swift.org> wrote:

>
>- What is your evaluation of the proposal?
>
> +1
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes.
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes.
>
>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> not applicable
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Followed the mailing list thread and read the proposal.
>
>
> On 01 Apr 2016, at 05:27, Douglas Gregor  > wrote:
>
> Hello Swift community,
>
> The review of SE-0056 "Allow trailing closures in `guard` conditions"
> begins now and runs through April 5, 2016. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>
> Reply text
>
> Other replies
>
> 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 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,
>
> Doug Gregor
>
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
>

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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Howard Lovatt via swift-evolution]

+1 Same as Matthew Johnson said

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

>
>
>- What is your evaluation of the proposal?
>
> +1.  The current behavior is surprising in a somewhat confusing way.
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes
>
>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> I haven’t used a language with leading dot shorthand so I don’t have a
> point of comparison.
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Followed the thread on the mailing list and read the proposal.
>
>

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

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

[Rob Mayoff via swift-evolution]

Check out the `testable` attribute:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347

Lots of examples if you type `swift testable` into your favorite search
engine.

On Fri, Apr 1, 2016 at 4:04 PM, John Heerema via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m a fan of test-driven development.
> I use it myself, and teach it to students and colleagues.
>
> One of the nice things about Swift 1.0 was that it was easy to write
> module tests.
>
> When access controls were introduced into Swift, I found that many
> functions and objects that had no genuine need to be public, suddenly had
> to become public in order to be tested. That just seems wrong to me.
>
> I’d like to see a way for tests, which are not normally part of the
> module, to have access to a module’s contents (I’m talking source only –
> not packages that do not include source). That might simply be a feature of
> the IDE, rather than a language feature.
>
> On another note, I see “file private” (whatever it’s called) as a legacy
> of C. I have trouble seeing it as being truly useful, but can see that
> others might have genuine uses for it (actually, I’d like to hear what they
> might be)
>
> Thanks,
> Dr. J. Heerema
>
>
>
> ___
> 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-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Matthew Johnson via swift-evolution]

> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> Douglas Gregor via swift-evolution
>  wrote:
>> Hello Swift community,
>> 
>> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance
>> Member Implementations" begins now and runs throughApril 5, 2016. The
>> proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.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. When replying, please try to keep the proposal link at
>> the top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>> Reply text
>> 
>> Other replies
>> 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 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,
>> 
>> Doug Gregor
>> 
>> Review Manager
> 
> This proposal seems to me like it's failing to fix the underlying problem,
> which is that people don't understand the leading dot rules, and papering
> over the problem by making the rule less consisten, with different behavior
> for enums and other type-scoped (static/class) entities. It doesn't seem
> like a principled solution to me. 

This proposal doesn’t change the leading dot rules at all.  What it does is 
make the rules for referencing static members *more* consistent than they are 
now, removing the special case for enum cases.

"Enumeration cases are essentially static not instance type members. Unlike 
static members in structures and classes, enumeration cases can be mentioned in 
initializers and instance methods without referencing a fully qualified type. 
This makes little sense. In no other case can an instance implementation 
directly access a static member."

I believe at one point in Swift’s history all static members could be 
referenced directly.  This proposal seems like it is cleaning up a case that 
was missed when that changed. 


> 
> -- 
> -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] SE-0025: Scoped Access Level, next

[David Hart via swift-evolution]

I’m fairly sure what you are asking for already exists with @testable: 
https://www.natashatherobot.com/swift-2-xcode-7-unit-testing-access/

> On 01 Apr 2016, at 23:04, John Heerema via swift-evolution 
>  wrote:
> 
> I’m a fan of test-driven development.
> I use it myself, and teach it to students and colleagues.
> 
> One of the nice things about Swift 1.0 was that it was easy to write module 
> tests.
> 
> When access controls were introduced into Swift, I found that many functions 
> and objects that had no genuine need to be public, suddenly had to become 
> public in order to be tested. That just seems wrong to me.
> 
> I’d like to see a way for tests, which are not normally part of the module, 
> to have access to a module’s contents (I’m talking source only – not packages 
> that do not include source). That might simply be a feature of the IDE, 
> rather than a language feature.
> 
> On another note, I see “file private” (whatever it’s called) as a legacy of 
> C. I have trouble seeing it as being truly useful, but can see that others 
> might have genuine uses for it (actually, I’d like to hear what they might be)
> 
> Thanks,
> Dr. J. Heerema 
> 
> 
> ___
> 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-0056: Allow trailing closures in `guard` conditions

[Rob Mayoff via swift-evolution]

I would prefer the conditional statements to treat trailing closures
consistently, rather than allow this minor but inconsistent convenience. I
don't think this needs changing. I read the proposal and followed the list
discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
-1 I admire the goal of making trailing closures usably in guard, but I do not 
like the inconsistency between guard and if. I also never liked the 
inconsistency with the else keyword in guard. Bother those reasons means that 
I’m worried that this will increase the cost of transforming guards into ifs, 
as can be quite frequent when refactoring code.

For example, transforming:

guard collection.contains { $0.predicate } else {
return
}

Would require more modification:

if !collection.contains({ $0.predicate }) {
return
}

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
I do not think so.

> Does this proposal fit well with the feel and direction of Swift?
I think this proposal has the danger of adding inconsistency, which is opposite 
to the direction of simplification for Swift 3.0

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Ruby uses keywords the conditional expression for the body of control 
structures (similar to guard’s else). Perhaps if Swift also adopted those would 
we be able to implement trailing closures in conditional expressions everywhere:

if condition then {
} else {
}

while condition do {
}

switch expression on {
}

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A thorough read and long thought.

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

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

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

[Ilya Belenkiy via swift-evolution]

Great! Glad that we have a decision.

On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 30, 2016, at 9:22 PM, Chris Lattner  wrote:
> >
> > I’ve seen a number of concerns on this list about moduleprivate, and how
> it penalizes folks who want to explicitly write their access control.  I’ve
> come to think that there is yes-another possible path forward here (which I
> haven’t seen mentioned so far):
> >
> > public
> > internal
> > fileprivate
> > private
>
> Hi Everyone,
>
> Thank you for all of the input.  I know that this was a highly contentious
> topic, that it is impossible to make everyone happy.  Getting the different
> inputs and perspectives has been very very useful.
>
> The core team met to discuss this, and settled on the list above:
> public/internal/fileprivate/private.  This preserves the benefit of the
> “fileprivate” concept that we have today in Swift, while aligning the
> “private” keyword with common expectations of people coming to Swift. This
> also makes “private" the "safe default” for cases where you don’t think
> about which one you want to use, and this schema will cause minimal churn
> for existing Swift code.
>
> Thank you again for all of the input and discussion!
>
> -Chris
>
> btw, to be clear, this is *not* an April 1 joke.
> ___
> 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-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Dave Abrahams via swift-evolution]

Douglas Gregor via swift-evolution
 wrote:
> Hello Swift community,
> 
> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance
> Member Implementations" begins now and runs throughApril 5, 2016. The
> proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.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. When replying, please try to keep the proposal link at
> the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
> Reply text
> 
> Other replies
>  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 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,
> 
> Doug Gregor
> 
> Review Manager

This proposal seems to me like it's failing to fix the underlying problem,
which is that people don't understand the leading dot rules, and papering
over the problem by making the rule less consisten, with different behavior
for enums and other type-scoped (static/class) entities. It doesn't seem
like a principled solution to me. 

-- 
-Dave

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Brent Royal-Gordon via swift-evolution]

> My apologies if this was previously discussed. Was there ever a reason given 
> for not using operators for set combiners? That is, | & - ^ for union, 
> intersection, subtracting, and symmetricDifference, and |= &= -= ^= for the 
> mutating versions.

With a few exceptions (like `+` for concatenation), Swift doesn't overload 
operators to give them different meanings, even if they're kinda similar if you 
squint enough.

* * *

My review follows:

> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md


>   • What is your evaluation of the proposal?

I'm in favor of the updated guidelines and new names; they are straightforward 
and understandable. I'm not entirely happy with `subtract` being different from 
the others, but contorting it to match seems unwise, particularly when we're 
trying to demonstrate the API guidelines.

I have some issues with the new `insert(_:)` return value:

* I'm not sure what the purpose is of returning the new value if a value is 
inserted. Couldn't we return an `Element?` containing the old value if there is 
one, or `nil` if there's a new value?

* If an `insert` might collide with several elements, shouldn't we return a set 
of all the colliding elements, instead of `nil`? (This would do away with the 
exception for `OptionSetType.insert`.)

* Whatever `insert` does, shouldn't `update(with:)` do the same thing? 
Particularly with regards to updating multiple elements?

* How far does this "don't throw away information that's hard to recalculate" 
principle go? Should the mutating operations like `formUnion` return some 
indication of the affected elements? Should the *nonmutating* ones?

* If we're going to officially support equal-but-distinct elements in the 
SetAlgebra API, shouldn't we have an equivalent to NSSet's `member(_:)` method?

We can try to work out these and other issues in this thread, but unless there 
are straightforward answers, I think the better move might be to sever the 
return value change and discuss it separately. It brings up a lot of subtle 
questions across the entire API.

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

Yes. These APIs need to be renamed.

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

Yes. It solves an important issue with the guidelines.

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

This API is superior to NSSet/NSMutableSet and Ruby's Set, which are the two 
set APIs I'm most familiar with.

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

On the naming issue, I participated heavily in the Threads of Infinite 
Bikeshedding.

On the return value issue, something slightly more than a quick reading.

-- 
Brent Royal-Gordon
Architechies

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

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

[John Heerema via swift-evolution]

I'm a fan of test-driven development.
I use it myself, and teach it to students and colleagues.

One of the nice things about Swift 1.0 was that it was easy to write module 
tests.

When access controls were introduced into Swift, I found that many functions 
and objects that had no genuine need to be public, suddenly had to become 
public in order to be tested. That just seems wrong to me.

I'd like to see a way for tests, which are not normally part of the module, to 
have access to a module's contents (I'm talking source only - not packages that 
do not include source). That might simply be a feature of the IDE, rather than 
a language feature.

On another note, I see "file private" (whatever it's called) as a legacy of C. 
I have trouble seeing it as being truly useful, but can see that others might 
have genuine uses for it (actually, I'd like to hear what they might be)

Thanks,
Dr. J. Heerema


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

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

[Wallacy via swift-evolution]

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution <
swift-evolution@swift.org> escreveu:

> With these names we lose consistency. The current scheme makes it very
> clear that each next level is a subset of the previous level. With
> "internal", fileprivate looks out of place.
>
> We have several goals for all the names:
> 1) obvious
> 2) using standard terms
> 3) short
> 4) consistent
>
> This discussion shows that we cannot have all of them. We have to pick
> something at the expense of something else.
>
> For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
> with this order
>
> public
> moduleprivate
> fileprivate
> private
>
> is the best so far.
>
> public
> internal
> fileprivate
> private
>
> is not as consistent. It's also not as obvious, given that many people
> proposed to use internal to mean fileprivate. The biggest advantages of
> these names are that there is less change and short words. If these are the
> most important goals, then my original proposal is even better:
>
> public
> internal
> private
> scoped
>
>
For me this is good, keep  untouched the actual public/internal/private and
just add a new word for the new access level.

It's a non-breaking change, everything retains its meaning, the added name
> is very clear, and all the names are very short. The biggest problem here
> is "private" -- it's not the most private that the language provides, and
> most people would expect that.
>
> Here is another one like that (it solves the "private" problem at the
> expense of using non-standard terms):
>
> public
> internal
> local
> scoped
>
> My main point is that we cannot have everything. We have to pick the order
> of importance.
>
> We heard many times that "short" is not the goal of Swift. Instead, it's
> clarity. If this is the case, then I think
>
> public
> moduleprivate
> fileprivate
> private
>
> is the clearest we've seen. Nobody could possibly be confused about the
> meaning of these names. I doubt that moduleprivate will be required to
> spell out in any style guide, but even so, it's not so bad. We have many
> frequently used class names that are much longer.
>
> On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>> > How about we continue this trend, and follow other existing Swift
>> keywords that merge two lowercase words (associatedtype, typealias, etc),
>> and use:
>> >
>> >   public
>> >   moduleprivate
>> >   fileprivate
>> >   private
>> >
>> > The advantages, as I see them are:
>> > 1) We keep public and private meaning the “right” and “obvious” things.
>> > 2) The declmodifiers “read” correctly.
>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>> awkward parenthesized keyword approach.
>> > 4) The unusual ones would be “googable”.
>> > 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>>
>> I’ve seen a number of concerns on this list about moduleprivate, and how
>> it penalizes folks who want to explicitly write their access control.  I’ve
>> come to think that there is yes-another possible path forward here (which I
>> haven’t seen mentioned so far):
>>
>> public
>> internal
>> fileprivate
>> private
>>
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) Compared to Swift 2, there is almost no change.  The only thing that
>> changes is that some uses of Swift 2 “private” will be migrated to
>> “fileprivate”, which makes the intent of the code much more clear.
>> 4) fileprivate is the unusual and
>> not-really-precedented-in-other-languages modifier, and it would still be
>> “googable”.
>> 5) The addresses the “excessively long” declmodifier problem that several
>> people are concerned with.
>> 6) Support for named submodules could be “dropped in” by parameterizing
>> “internal”.
>>
>> Thoughts?
>>
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0059: Update API Naming - leading dot prefix for enum instances.

[John Heerema via swift-evolution]

If I may, I would like to express support for NOT making this change.

One of Swift's really nice features is its ability to remove unnecessary 
syntactic cruft in cases where the context makes it possible for the compiler 
to infer a type or name. It's one of Swift's best features, and I would hate to 
see it chipped away.

I feel that Swift's existing syntax is superior to the proposal to require a 
leading dot prefix for enum instances. The simple reasons are readability, 
flexibility, and brevity. Swift is already smart enough to let developers skip 
the tedious qualification of enums in many cases.

If someone feels that a leading dot for enum cases  inside enum implementations 
makes their code clearer, there is nothing stopping them from doing so, and 
encouraging others to follow their lead. If the vast majority of developers 
voluntarily started doing so, I might even support this proposal. I don't think 
they will though.

Making a dot prefix mandatory here I feel, chips away at one of Swift's rather 
nice features, without a clear benefit.

In general, making things mandatory, rather than a matter of  stylistic choice, 
is unlikely to endear the language to developers - and I'd really like to see 
Swift succeed in a big way.

Thanks,
Dr. J. Heerema

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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Evan Maloney via swift-evolution]

> What is your evaluation of the proposal?
+1.

In addition to bringing greater consistency, requiring the leading dot will 
make it easier to grep one's codebase for enum case values.

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

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

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

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

Followed the mailing list discussion and read the proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Catching NSException

[Evan Maloney via swift-evolution]

Hi Jon,

I ran into a similar situation and needed a way to not only catch NSExceptions 
from Swift, but throw them as well. If it would he useful to you, it's part of 
the open-source CleanroomBridging module, which is intended to ease a few 
Swift/ObjC interoperability issues. The header file for the exception-related 
code is here:

https://github.com/emaloney/CleanroomBridging/blob/master/Sources/Exception.h 


It is included in the module's bridging header, so you can use it from Swift.

Evan




> On Mar 24, 2016, at 2:06 PM, Jon Brooks via swift-evolution 
>  wrote:
> 
> Apologies if this has come up before - I've fallen behind in following this 
> list.
> 
> I recently ran into an issue where I needed to be able to catch NSExceptions 
> raised by Objective C API in Swift, and found no good way to do that.  
> Currently the only possible way is to via Objective C code that wraps the 
> call in an Objective C style @try/@catch block.  If building a swift 
> framework, this means a separate module, since we can't use bridging headers.
> 
> My quick attempt at a workaround can be seen here: 
> https://github.com/jonbrooks/ObjCTryCatch 
>  and there are other workarounds 
> out there too.  I wondered if there has been any discussion to building 
> something like this into swift directly.  I don't really have any good ideas, 
> but maybe something like
> 
> do {
> objc_try someObjectiveCInstance.methodThatMightRaiseException()
> } catch {
> //error would be an ErrorType that contains info about the exception 
> raised, or the exception itself?
> }
> 
> Any thoughts?
> 
> 
> 
> ___
> 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] Question about heterogeneous collections

[Jason Sadler via swift-evolution]

Ugh, sorry to spam the list like this (and also sorry I broke the threading…)
Dave’s hint to use “when Element == MyProtocol” 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013922.html)
 worked great for the example that I posted but falls down in some other cases. 
I count three possibilities:

0. (original case…now works) My array is [MyProtocol]
1.  If my array is [SimpleStruct] (where SimpleStruct : MyProtocol) I get 
“‘MyProtocol’ is not convertible to ‘SimpleStruct’”
2.  If my array is [SubProtocol] (where SubProtocol : MyProtocol) I get “Type 
‘MyProtocol’ does not conform to protocol ‘SubProtocol’”

I can work around #1 by duplicating my extension to CollectionType for both 
Element : MyProtocol *and* Element == MyProtocol, but that’s less than ideal. 
And I’m not sure if solving #2 is possible in this situation. (Unfortunately 
for me, #2 is actually what I’m trying to do in my app.)


> On Apr 1, 2016, at 2:38 PM, Jason Sadler  wrote:
> 
> I should double check before I post. That Stack Overflow question has the 
> same answer Dave posted earlier in this thread, which is more correct - it 
> just has fewer votes, and isn’t marked as the accepted answer. Sorry!
> 
>> On Apr 1, 2016, at 2:32 PM, Jason Sadler  wrote:
>> 
>> Thanks everyone for your answers - this has helped p a lot. However because 
>> I’m not a language design pro, I’m a little unclear still on what the 
>> difference is between `Element == MyProtocol` and `Element: MyProtocol`. 
>> Obviously the latter is “Element conforms to MyProtocol” but I don’t know 
>> how to make an English sentence out of the former.
>> 
>> I re-read some of the Generics chapter in the Swift book this morning but I 
>> wasn’t able to solidify my model of these two concepts.  Based on the lack 
>> of information when searching on Stack Overflow (the most helpful thing I’ve 
>> found was this, which suggests putting things in a box: 
>> http://stackoverflow.com/questions/33112559/protocol-doesnt-conform-to-itself/33524927#33524927)
>>  and asking on swift-users, could I suggest that this could use some more 
>> explicit documentation somewhere?
>> 
>> Thanks again,
>> Jason
> 

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

Re: [swift-evolution] Enable omitting `let` for constant declarations

[Yuta Koshizawa via swift-evolution]

Did you mean the thread "Mutability inference"? What I talked about is
different from it. I am against the idea of "Mutability inference".

What I talked about is just enabling to omit `let` for constant
declarations. It distinguishes the following three explicitly.

> - assignment
> - declaration of a constant
> - declaration of a mutable variable

`:=` makes it possible to distinguish assignments and constant declarations.

-- Yuta


2016-04-01 23:55 GMT+09:00 Radosław Pietruszewski :
> I can’t easily find it, but there’s been at least one thread proposing this 
> exact thing, and there was very little interest in the proposal.
>
> TL;DR is that Swift *by design* wants to make the difference between these 
> three concepts:
>
> - assignment
> - declaration of a constant
> - declaration of a mutable variable
>
> as explicit and obvious as possible.
>
> — Radek
>
>> On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution 
>>  wrote:
>>
>> I think it would be good if the following three declarations were equivalent
>>
>> let a: Int = 42
>> a: Int = 42
>> a := 42
>>
>> and also the following two were.
>>
>> let a: Int
>> a: Int
>>
>> Then constant declarations become shorter than variable declarations.
>> It encourages people to use constants in preference to variables.
>>
>> It also prevents repeating `let` for property declarations and makes
>> type declarations simpler.
>>
>> struct Person {
>>firstName: String
>>lastName: String
>>age: Int
>> }
>>
>> Omitting `let` is consistent with that we don't write `let` for
>> arguments of functions and iterated values in for-in loops.
>>
>> Not `=` but `:=` for type inferences because `=` cannot distinguish
>> whether it means a constant declaration or an assignment to a variable
>> declared in an outer scope. I think `:=` is a natural notation for
>> type inferences because omitting the type from `a: Int = 42` makes
>> `a:= 42`. Because I have not strictly checked if it can be parsed in
>> Swift properly, it may have some other parsing issues.
>>
>> What do you think about it?
>>
>> -- Yuta
>> ___
>> 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] Question about heterogeneous collections

[Jason Sadler via swift-evolution]

I should double check before I post. That Stack Overflow question has the same 
answer Dave posted earlier in this thread, which is more correct - it just has 
fewer votes, and isn’t marked as the accepted answer. Sorry!

> On Apr 1, 2016, at 2:32 PM, Jason Sadler  wrote:
> 
> Thanks everyone for your answers - this has helped p a lot. However because 
> I’m not a language design pro, I’m a little unclear still on what the 
> difference is between `Element == MyProtocol` and `Element: MyProtocol`. 
> Obviously the latter is “Element conforms to MyProtocol” but I don’t know how 
> to make an English sentence out of the former.
> 
> I re-read some of the Generics chapter in the Swift book this morning but I 
> wasn’t able to solidify my model of these two concepts.  Based on the lack of 
> information when searching on Stack Overflow (the most helpful thing I’ve 
> found was this, which suggests putting things in a box: 
> http://stackoverflow.com/questions/33112559/protocol-doesnt-conform-to-itself/33524927#33524927)
>  and asking on swift-users, could I suggest that this could use some more 
> explicit documentation somewhere?
> 
> Thanks again,
> Jason

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

Re: [swift-evolution] Question about heterogeneous collections

[Jason Sadler via swift-evolution]

Thanks everyone for your answers - this has helped p a lot. However because I’m 
not a language design pro, I’m a little unclear still on what the difference is 
between `Element == MyProtocol` and `Element: MyProtocol`. Obviously the latter 
is “Element conforms to MyProtocol” but I don’t know how to make an English 
sentence out of the former.

I re-read some of the Generics chapter in the Swift book this morning but I 
wasn’t able to solidify my model of these two concepts.  Based on the lack of 
information when searching on Stack Overflow (the most helpful thing I’ve found 
was this, which suggests putting things in a box: 
http://stackoverflow.com/questions/33112559/protocol-doesnt-conform-to-itself/33524927#33524927)
 and asking on swift-users, could I suggest that this could use some more 
explicit documentation somewhere?

Thanks again,
Jason
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Chris Lattner via swift-evolution]

> On Mar 31, 2016, at 11:43 PM, Fabian Ehrentraud 
>  wrote:
> 
> Great to hear IUOs losing ground :-)
> 
> Might adding additional compiler warnings as described in SR-104 accompany 
> the implementation of this proposal well?
> https://bugs.swift.org/browse/SR-104 
This is definitely related, but orthogonal to SE-0054.  

Just MHO, but I think warning on every implicit unwrap would completely defeat 
the point of having the T! feature in the first place: if that were the model 
we wanted, we would just import unaudited pointers as optional.  Doing that has 
been extensively discussed and is not a good idea.

-Chris

> 
> Fabian
> 
> 
>> On 31.03.2016, at 18:43, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
>>  
>> 
>> 
>> The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from 
>> Mar 25…30, 2016. The proposal has been *accepted, pending implementation 
>> experience*:
>> 
>> There is generally positive feedback on the proposal, as it keeps the good 
>> behaviors of the existing T! type syntax (including support for importing 
>> un-nullability-audited APIs, support for 2-phase initialization patterns, 
>> etc) while dramatically reducing the confusion and surprise that they 
>> introduce as they trickle through type inference.  The core team sees 
>> significant value in having a simple and predictable model that can be 
>> explained concisely. 
>> 
>> That said, this is the sort of proposal that can have a profound impact on 
>> the actual experience using unaudited APIs.  The core team believes that the 
>> experience will be good, but we would like to get some experience moving a 
>> couple of existing projects (both low-level code that interacts with C, and 
>> an “App” project working with high level frameworks) to see what the impact 
>> is in practice.  If something unexpected comes up, we will revisit this, and 
>> potentially reject it later.  Chris Willmore is working on an implementation 
>> of this now, so we should know in the next week or two.
>> 
>> Thank you to Chris Willmore for driving this forward!
>> 
>> -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] A shortcut for weakly referencing functions

[Joe Groff via swift-evolution]

As we briefly discussed on Twitter, I feel like Swift already has too much 
closure syntax as it is. { [unowned self] self.doSomething($0) } is definitely 
more text than self.doSomething, but it's clear what it's doing. 
"self.doSomething" method applications are also the only place where we 
directly capture an object into a closure without explicit closure syntax, 
which is where much of the surprise about memory leaks comes from. Even when 
strong references are desired, it's arguable that { self.doSomething($0) } is 
still preferable, since it's more obviously capturing `self`, and that the 
'self.doSomething' shorthand is a misfeature.

-Joe

> On Apr 1, 2016, at 8:09 AM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> Here’s a pattern I find myself doing quite often:
> 
>  1> class Child {
>  2. var onSomeEvent: () -> Void = { }
>  3. }
>  4> class Parent {
>  5. let child = Child()
>  6. init() {
>  7. child.onSomeEvent = doSomething
>  8. }
>  9. func doSomething() {
> 10. }
> 11. }
> 
> I have some ownership hierarchy of classes (often controllers — view 
> controllers — views), where I pass information from children up to parents 
> using closures set by the parent.
> 
> I like this pattern because children classes don’t have to be tied to 
> knowledge about their parents, and I don’t have to define delegate protocols. 
> It’s very clean, and also very easy to set up.
> 
> The only problem is that there’s a strong danger of introducing reference 
> cycles.
> 
> With class properties, you can quite easily see the potential for a reference 
> cycle and mark references to parents with weak/unowned. And with `self` 
> captures in closures, you’re reminded of memory management by having to be 
> explicit about `self`. But when passing references from parents to children, 
> there’s no way to mark the closure property as `weak` (and there’s no 
> reminder of the danger).
> 
> * * *
> 
> Right now, every time I pass a closure down to children, I have to wrap my 
> references like so:
> 
>   { [unowned self] self.doSomething($0) }
> 
> instead of a neat and simple function reference:
> 
>   doSomething
> 
> I think it would be useful to have a shortcut syntax for creating weak and 
> unowned references to functions, like so:
> 
>   @unowned(doSomething)
> 
> or perhaps:
> 
>   #unowned(self.doSomething)
> 
> * * *
> 
> An alternative would be the ability to mark closure properties as weak or 
> unowned. Then I could, at the *child* level, say:
> 
>   unowned let onSomeEvent: () -> Void
> 
> * * *
> 
> Does this make sense? What do you think?
> 
> — Radek
> 
> ___
> 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] SE-0025: Scoped Access Level, next steps

[Xiaodi Wu via swift-evolution]

In terms of alternatives to fileprivate, I just want to chime in to say
that "filewide" seems to be a term that people seem to reach for in
describing this scope, based on a quick Google search.

It's readable, IMO, and definitely an adjective, it breaks no new ground in
terms of coining a new term, and it is adequately descriptive. Plus, it
avoids the issue of having two things named fileprivate and [bona fide]
private.

For those reasons, it's got my vote over "file", "fileprivate", "infile",
"intrafile", etc.

On Fri, Apr 1, 2016 at 11:11 AM Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> How about:
>
> notprivateatall
> notveryprivate
> mostlyprivate
> stayout!!!private
>
> Sorry. April fools.. :-)
>
> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> "or within my whole program (external)". That caused a double-take on its
> own.
>
> external things are not within, they are outside. 'external' could be a
> replacement term for 'public', not for 'internal'.
>
> This may well be a subjective thing, but I don't think in files, I think
> in modules because that's been the default for several years now. If I
> create a new type I am implicitly making it visible to everywhere within
> this module; it is not outside the module so it is not external. I may then
> choose to make it less visible, but it does not 'go inside' when I do this.
>
> If you think in files, I cannot say you are wrong, because it is
> subjective. But this is why I have been arguing for non-subjective
> keywords. I cannot make 'fileprivate' pretty for you but I do know that
> when we both read it we both understand what it means. That's why it hasn't
> gone away: it satisfies the criterion of clarity.
>
> Find a pretty alternative with the word 'file' baked into it and I'm with
> you.
>
> On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  wrote:
>
>> A new type is implicitly visible *outside* of the file it is defined in
>> and hence it is “external” from that point of view. This arrangement seems
>> more “human” to me. Someone just learning isn’t going to know about modules
>> or how the compiler is treating things anyway and they would almost never
>> run into “external” because it’s the default and there’s no reason to
>> specify it most of the time. IMO, this “fits” how I think about source code
>> while I’m writing it - where do I want to be able to use this symbol?
>> Either hidden away and safe (private), inside this file I’m working with
>> (internal), or within my whole program (external).
>>
>> l8r
>> Sean
>>
>>
>> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien 
>> wrote:
>> >
>> > A new type is implicitly internal to a module. Implicitly specifying it
>> as 'external' is just plain confusing.
>> >
>> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > I know this is kind of winding down, and there seems to be a kind of
>> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
>> but I still really don’t like it so I’m going to toss out my current
>> favorite configuration and try to stop caring and defer to the core team to
>> make an executive decision so we can all move on with our lives. :P
>> >
>> > public - unchanged, visible “everywhere"
>> > external - visible outside of the file (module, the default)
>> > internal - visible only within the file
>> > private - visible only within the scope
>> >
>> > I really like the existing private and I use it a lot to build
>> collections of small classes and structs that work together rather than a
>> large class/struct that tries to “be everything”. In those scenarios,
>> traditional OO private would be too restrictive and even a “protected”
>> access type wouldn’t work because I’m trying to avoid building inheritance
>> hierarchies. I really need something like “friend” (ugly) or the, imo, much
>> more elegant file-scoped access and if that one is renamed “fileprivate”
>> I’ll be really sad seeing such an ugly label all over the place. I’d go so
>> far as to suggest that an ugly name for this access level would actively
>> discourage its use and while some might have that as a goal, to me that
>> would encourage the creation of larger “do everything” classes instead of
>> clusters of smaller classes and structs and protocols.
>> >
>> > l8r
>> > Sean
>> >
>> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > >
>> > >> I’ve seen a number of concerns on this list about moduleprivate, and
>> how it penalizes folks who want to explicitly write their access control.
>> I’ve come to think that there is yes-another possible path forward here
>> (which I haven’t seen mentioned so far):
>> > >>
>> > >> public
>> > >> internal
>> > >> fileprivate
>> > >> private
>> > >>
>> > >> The advantages, as I see them are:
>> > >> 1) We keep public 

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

[Ankit Agarwal via swift-evolution]

On Fri, Apr 1, 2016 at 10:45 PM, Max Howell  wrote:

> I’m wondering if the dev package should be inside Packages in some manner,
> perhaps as a symlink.
>
> Otherwise when you looks inside Packages you don't see all your
> dependencies.
>

Since as per current design dev packages will only be included if it is in
the `swift build` command I don't think its ever a concrete dependency to
be inside `Packages/` in any way.


> Also since this is related to the lockfile work, I’d like to wait until
> that is done, probably we could use very similar command line UX.
>
> If you don’t mind?
>

Cool.

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

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

[Max Howell via swift-evolution]

I’m wondering if the dev package should be inside Packages in some manner, 
perhaps as a symlink.

Otherwise when you looks inside Packages you don't see all your dependencies.

Also since this is related to the lockfile work, I’d like to wait until that is 
done, probably we could use very similar command line UX.

If you don’t mind?

I’ll revise the lockfile proposal today and get it moving.

Thanks for all your great work 

> If this looks good can we move ahead for review ?

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Thorsten Seitz via swift-evolution]

Good point. That would obviously restrict the choice for naming the methods in 
such a protocol, but since we are talking about new protocols that would not be 
an impediment. It might result in non-optimal method names, of course.

-Thorsten 

> Am 31.03.2016 um 18:37 schrieb Rob Mayoff via swift-evolution 
> :
> 
>> On Thu, Mar 31, 2016 at 10:56 AM, Thorsten Seitz via swift-evolution 
>>  wrote:
> 
>> 
>> protocol UIGestureRecognizerDelegate {
>> var gestureRecognizerShouldBegin: ((gestureRecognizer: 
>> UIGestureRecognizer) -> Bool)? { get }
>> }
> 
> UIGestureRecognizerDelegate has five methods that are "named" 
> gestureRecognizer:
> 
> gestureRecognizer(_:shouldRecognizeSimultaneouslyWithGestureRecognizer:)
> gestureRecognizer(_:shouldRequireFailureOfGestureRecognizer:)
> gestureRecognizer(_:shouldBeRequiredToFailByGestureRecognizer:)
> gestureRecognizer(_:shouldReceiveTouch:)
> gestureRecognizer(_:shouldReceivePress:)
> You can only have a single property named "gestureRecognizer", so you either 
> have to come up with other names for these, or change the language to allow 
> closure-typed properties to have multipart names.
> 
> This problem has been noted before, for example here: 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/8707/
> 
> ___
> 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] A shortcut for weakly referencing functions

[Radosław Pietruszewski via swift-evolution]

>> Here’s a pattern I find myself doing quite often:
>> 
>>  1> class Child {
>>  2. var onSomeEvent: () -> Void = { }
>>  3. }
>>  4> class Parent {
>>  5. let child = Child()
>>  6. init() {
>>  7. child.onSomeEvent = doSomething
>>  8. }
>>  9. func doSomething() {
>> 10. }
>> 11. }
>> 
>> I have some ownership hierarchy of classes (often controllers — view
>> controllers — views), where I pass information from children up to
>> parents using closures set by the parent.
>> 
>> I like this pattern because children classes don’t have to be tied to
>> knowledge about their parents, and I don’t have to define delegate
>> protocols. It’s very clean, and also very easy to set up.
>> 
>> The only problem is that there’s a strong danger of introducing reference
>> cycles.
>> 
>> With class properties, you can quite easily see the potential for a
>> reference cycle and mark references to parents with weak/unowned. And
>> with `self` captures in closures, you’re reminded of memory management by
>> having to be explicit about `self`. But when passing references from
>> parents to children, there’s no way to mark the closure property as
>> `weak` (and there’s no reminder of the danger).
> 
> I will go ahead and note, at least in terms of writing the proposal, I
> don't find this argument very strong. The proposed syntax still requires
> you to know about the cycles involved.

Oh, I agree. The proposal doesn’t fix the relative undiscoverability (is that a 
word?) of the potential for reference cycles when passing function references.

Still — I think, maybe, when you can say in tutorials and programming guides 
that you avoid reference cycles when passing functions down the ownership 
hierarchy by wrapping those function references in #weak(…) / #unowned(…), it 
might be easier to grasp and remember than `{ [unowned self] in self.foo($0) }`.

> 
>> 
>> * * *
>> 
>> Right now, every time I pass a closure down to children, I have to wrap
>> my references like so:
>> 
>>  { [unowned self] self.doSomething($0) }
>> 
>> instead of a neat and simple function reference:
>> 
>>  doSomething
>> 
>> I think it would be useful to have a shortcut syntax for creating weak
>> and unowned references to functions, like so:
>> 
>>  @unowned(doSomething)
>> 
>> or perhaps:
>> 
>>  #unowned(self.doSomething)
>> 
>> * * *
> 
> I really like the #unowned syntax! It's expressive and in line with
> other pieces of Swift sugar. Would +1 if it came to a proposal!
> 
> The @ version doesn't make as much sense as it's not an attribute.

Thank you. You’re probably right about #unowned(…) vs @unowned(…). I thought of 
at-syntax because it feels like applying an attribute to the function 
reference. (IIRC, weak and unowned were @weak and @unowned in Swift β1)

> 
>> 
>> An alternative would be the ability to mark closure properties as weak or
>> unowned. Then I could, at the *child* level, say:
>> 
>>  unowned let onSomeEvent: () -> Void
> 
> I don't particularly think it makes sense, because it is prescriptive.
> If some other user in your codebase wanted the cycle, they couldn't get
> it. Plus, what would it mean when the closure isn't capturing anything?

Rright. Because it’s not really about assigning literal closures to such a 
parameter, rather assigning method references, where the method’s receiver 
(self in my example) is implicitly captured… So it seems like it should be a 
responsibility of the code assigning the reference.

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

Re: [swift-evolution] SetAlgebra naming update

[Thorsten Seitz via swift-evolution]

> Am 31.03.2016 um 19:53 schrieb Dave Abrahams :
> 
> 
>> on Thu Mar 31 2016, Thorsten Seitz  wrote:
>> 
>> Am 30. März 2016 um 17:48 schrieb Dave Abrahams :
>> 
>>on Wed Mar 30 2016, Thorsten Seitz  wrote:
>> 
>>Am 30.03.2016 um 16:49 schrieb Dave Abrahams 
>> :
>> 
>>on Wed Mar 30 2016, Thorsten Seitz 
>>  wrote:
>> 
>>That's certainly an improvement, but why 
>> "formIntersection" instead of
>> 
>>"intersect" (in analogy to "subtract")?
>> 
>>1. Consistency with union, which is more closely related than 
>> subtract.
>> 
>>I'd prefer consistency with the verb rule here
>> 
>>Which rule is that? As far as I can tell, this is consistent with all
>>the rules.
>> 
>> "Those with side-effects should read as imperative verb phrases"
> 
> “form ” is an imperative verb phrase.
> 
>> I expect a common verb to be chosen over an awkward, constructed one,
>> although I have to admit that the verb "intersect" is used only very
>> seldom if at all in set theory or geometry.  Therefore you might have
>> a point with "intersect" having the wrong implication, but see below.
>> 
>>(using formXXX only as last resort).
>> 
>>Though I prefer not to, you can look at this as a last resort if you
>>like; the alternative you're proposing has the wrong implication, so it
>>is not a candidate. It would be like using “remainder” as a verb for
>>integers. Yes, it's a legitimate verb, but it means the wrong thing
>>(see retail).
>> 
>>2. "Intersect" actually has the wrong meaning as an 
>> imperative. If you
>> 
>>tell set A to intersect set B, and then ask whether A intersects B
>> 
>>(!A.isDisjoint(with: B)), you would expect an answer of true.
>> 
>>Sorry, but I do not agree. With that reasoning I would have to expect
>> 
>>a.intersection(b) to be not empty.
>> 
>>Yes, that's exactly what I'm saying. If you tell A to intersect B,
>>presumably when the call completes, A intersects B (i.e. has a non-empty
>>intersection). That would imply an implementation like, e.g.
>> 
>> With a.intersection(b) I meant to extend your reasoning to the
>> non-mutating method. 
>> 
>> You surely do not expect the intersection of a and b to be non-empty
>> when calling the non-mutating method? 
> 
> No I do not.
> 
>> Then why should you expect that in the mutating case?  
> 
> for the same reason that 
> 
>shape1.encloses(shape2)
> 
> might return true or false but
> 
>shape1.enclose(shape2)
> 
> has to change shape1 so it encloses shape2.

Thanks! That's a very good example!

-Thorsten 

>> Is it because the noun implies a current state whereas the verb should
>> be read as a command demanding to create a certain state? (I'm not a
>> native speaker, so please bear with me)
> 
> I think that's a pretty good explanation.
> 
> HTH,
> 
> -- 
> Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Ossenbruggen via swift-evolution]

How about: 

notprivateatall
notveryprivate
mostlyprivate
stayout!!!private

Sorry. April fools.. :-) 

> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> "or within my whole program (external)". That caused a double-take on its own.
> 
> external things are not within, they are outside. 'external' could be a 
> replacement term for 'public', not for 'internal'.
> 
> This may well be a subjective thing, but I don't think in files, I think in 
> modules because that's been the default for several years now. If I create a 
> new type I am implicitly making it visible to everywhere within this module; 
> it is not outside the module so it is not external. I may then choose to make 
> it less visible, but it does not 'go inside' when I do this.
> 
> If you think in files, I cannot say you are wrong, because it is subjective. 
> But this is why I have been arguing for non-subjective keywords. I cannot 
> make 'fileprivate' pretty for you but I do know that when we both read it we 
> both understand what it means. That's why it hasn't gone away: it satisfies 
> the criterion of clarity.
> 
> Find a pretty alternative with the word 'file' baked into it and I'm with you.
> 
> On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  > wrote:
> A new type is implicitly visible *outside* of the file it is defined in and 
> hence it is “external” from that point of view. This arrangement seems more 
> “human” to me. Someone just learning isn’t going to know about modules or how 
> the compiler is treating things anyway and they would almost never run into 
> “external” because it’s the default and there’s no reason to specify it most 
> of the time. IMO, this “fits” how I think about source code while I’m writing 
> it - where do I want to be able to use this symbol? Either hidden away and 
> safe (private), inside this file I’m working with (internal), or within my 
> whole program (external).
> 
> l8r
> Sean
> 
> 
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien  > > wrote:
> >
> > A new type is implicitly internal to a module. Implicitly specifying it as 
> > 'external' is just plain confusing.
> >
> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution 
> > > wrote:
> > I know this is kind of winding down, and there seems to be a kind of 
> > begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), 
> > but I still really don’t like it so I’m going to toss out my current 
> > favorite configuration and try to stop caring and defer to the core team to 
> > make an executive decision so we can all move on with our lives. :P
> >
> > public - unchanged, visible “everywhere"
> > external - visible outside of the file (module, the default)
> > internal - visible only within the file
> > private - visible only within the scope
> >
> > I really like the existing private and I use it a lot to build collections 
> > of small classes and structs that work together rather than a large 
> > class/struct that tries to “be everything”. In those scenarios, traditional 
> > OO private would be too restrictive and even a “protected” access type 
> > wouldn’t work because I’m trying to avoid building inheritance hierarchies. 
> > I really need something like “friend” (ugly) or the, imo, much more elegant 
> > file-scoped access and if that one is renamed “fileprivate” I’ll be really 
> > sad seeing such an ugly label all over the place. I’d go so far as to 
> > suggest that an ugly name for this access level would actively discourage 
> > its use and while some might have that as a goal, to me that would 
> > encourage the creation of larger “do everything” classes instead of 
> > clusters of smaller classes and structs and protocols.
> >
> > l8r
> > Sean
> >
> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution 
> > > > wrote:
> > >
> > >> I’ve seen a number of concerns on this list about moduleprivate, and how 
> > >> it penalizes folks who want to explicitly write their access control.  
> > >> I’ve come to think that there is yes-another possible path forward here 
> > >> (which I haven’t seen mentioned so far):
> > >>
> > >> public
> > >> internal
> > >> fileprivate
> > >> private
> > >>
> > >> The advantages, as I see them are:
> > >> 1) We keep public and private meaning the “right” and “obvious” things.
> > >> 2) The declmodifiers “read” correctly.
> > >> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> > >> changes is that some uses of Swift 2 “private” will be migrated to 
> > >> “fileprivate”, which makes the intent of the code much more clear.
> > >> 4) fileprivate is the unusual and 
> > >> not-really-precedented-in-other-languages modifier, and it would still 
> > >> be 

Re: [swift-evolution] A shortcut for weakly referencing functions

[Zach Waldowski via swift-evolution]

Responses inline!

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Fri, Apr 1, 2016, at 11:09 AM, Radosław Pietruszewski via
swift-evolution wrote:
> Here’s a pattern I find myself doing quite often:
> 
>   1> class Child {
>   2. var onSomeEvent: () -> Void = { }
>   3. }
>   4> class Parent {
>   5. let child = Child()
>   6. init() {
>   7. child.onSomeEvent = doSomething
>   8. }
>   9. func doSomething() {
>  10. }
>  11. }
> 
> I have some ownership hierarchy of classes (often controllers — view
> controllers — views), where I pass information from children up to
> parents using closures set by the parent.
> 
> I like this pattern because children classes don’t have to be tied to
> knowledge about their parents, and I don’t have to define delegate
> protocols. It’s very clean, and also very easy to set up.
> 
> The only problem is that there’s a strong danger of introducing reference
> cycles.
> 
> With class properties, you can quite easily see the potential for a
> reference cycle and mark references to parents with weak/unowned. And
> with `self` captures in closures, you’re reminded of memory management by
> having to be explicit about `self`. But when passing references from
> parents to children, there’s no way to mark the closure property as
> `weak` (and there’s no reminder of the danger).

I will go ahead and note, at least in terms of writing the proposal, I
don't find this argument very strong. The proposed syntax still requires
you to know about the cycles involved.

> 
> * * *
> 
> Right now, every time I pass a closure down to children, I have to wrap
> my references like so:
> 
>   { [unowned self] self.doSomething($0) }
> 
> instead of a neat and simple function reference:
> 
>   doSomething
> 
> I think it would be useful to have a shortcut syntax for creating weak
> and unowned references to functions, like so:
> 
>   @unowned(doSomething)
> 
> or perhaps:
> 
>   #unowned(self.doSomething)
> 
> * * *

I really like the #unowned syntax! It's expressive and in line with
other pieces of Swift sugar. Would +1 if it came to a proposal!

The @ version doesn't make as much sense as it's not an attribute.

> 
> An alternative would be the ability to mark closure properties as weak or
> unowned. Then I could, at the *child* level, say:
> 
>   unowned let onSomeEvent: () -> Void

I don't particularly think it makes sense, because it is prescriptive.
If some other user in your codebase wanted the cycle, they couldn't get
it. Plus, what would it mean when the closure isn't capturing anything?

> 
> * * *
> 
> Does this make sense? What do you think?
> 
> — Radek
> 
> ___
> 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] Question about heterogeneous collections

[Maximilian Hünenberger via swift-evolution]

See inline

> Am 31.03.2016 um 20:14 schrieb Dave Abrahams via swift-evolution 
> :
> 
> 
>> on Tue Mar 29 2016, Jason Sadler  wrote:
>> 
>> Hi folks,
>> 
>> I have an issue with using a heterogeneous array of objects conforming
>> to a protocol - I want to write an extension on Array (or
>> CollectionType) that applies only when Element : MyProtocol, but I
>> can’t call methods in that extension from an instance of [MyProtocol]
>> because "Using ‘MyProtocol' as a concrete type conforming to protocol
>> ‘MyProtocol' is not supported”
> 
> Hint: write your extension so it applies when Element == MyProtocol instead.
> 

Why don't we also imply `Element == MyProtocol` when using `Element: 
MyProtocol` ?

Both extensions can have the exact same functions/implementation.
Am I missing something?
I currently don't see why we are forced to distinguish between homogeneous and 
heterogeneous Collections.

Kind regards
- Maximilian

>> (For more background, my full use case can be seen in this gist: 
>> https://gist.github.com/sadlerjw/2cc16b4375b02fe7f400)
>> 
>> I’ve asked about this on swift-users
>> (https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160321/001560.html)
>> and got some good workarounds but no one was able to provide me with
>> information on any future plans in swift to address this issue -
>> whether that’s making protocols conform to themselves, or some other
>> improved approach to heterogeneous collections. I wonder if anyone
>> here can shed some light on this? (I’m new to the mailing lists,
>> sorry!)
> 
> -- 
> 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

[swift-evolution] A shortcut for weakly referencing functions

[Radosław Pietruszewski via swift-evolution]

Here’s a pattern I find myself doing quite often:

  1> class Child {
  2. var onSomeEvent: () -> Void = { }
  3. }
  4> class Parent {
  5. let child = Child()
  6. init() {
  7. child.onSomeEvent = doSomething
  8. }
  9. func doSomething() {
 10. }
 11. }

I have some ownership hierarchy of classes (often controllers — view 
controllers — views), where I pass information from children up to parents 
using closures set by the parent.

I like this pattern because children classes don’t have to be tied to knowledge 
about their parents, and I don’t have to define delegate protocols. It’s very 
clean, and also very easy to set up.

The only problem is that there’s a strong danger of introducing reference 
cycles.

With class properties, you can quite easily see the potential for a reference 
cycle and mark references to parents with weak/unowned. And with `self` 
captures in closures, you’re reminded of memory management by having to be 
explicit about `self`. But when passing references from parents to children, 
there’s no way to mark the closure property as `weak` (and there’s no reminder 
of the danger).

* * *

Right now, every time I pass a closure down to children, I have to wrap my 
references like so:

{ [unowned self] self.doSomething($0) }

instead of a neat and simple function reference:

doSomething

I think it would be useful to have a shortcut syntax for creating weak and 
unowned references to functions, like so:

@unowned(doSomething)

or perhaps:

#unowned(self.doSomething)

* * *

An alternative would be the ability to mark closure properties as weak or 
unowned. Then I could, at the *child* level, say:

unowned let onSomeEvent: () -> Void

* * *

Does this make sense? What do you think?

— Radek

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

Re: [swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski via swift-evolution]

> On 31 Mar 2016, at 16:08, Erica Sadun  wrote:
> 
>> 
>> On Mar 31, 2016, at 5:56 AM, Radosław Pietruszewski > > wrote:
>>> I follow the "Rule of Kevin", which is not language enforced. Parens around 
>>> functional 
>>> closures (->T), not around procedural (->Void) ones.  This promotes 
>>> "language construct"-like 
>>> Void calls, avoids compiler parsing issues when chaining (or using "guard", 
>>> "if", etc). It lets
>>> me know instantly how the closure is used. 
>>> 
>>> While I was originally reluctant to adopt it, its advantages have become 
>>> self-evident over time. 
>>> This ends up being slightly wordier, especially in the few cases you need 
>>> to use argument labels. 
>>> 
>>> I think it's worth it.
>> 
>> I don’t follow the Rule of Kevin myself, although I’m not against it either, 
>> and I see why some people would like it.
>> 
>> But, if we’re going to have trailing closures at all (which seems desirable 
>> for creating things that look like language features), enforcement based on 
>> syntactic preference doesn’t make sense to me.
>> 
>> This really reminds me of a “remove implicit self” discussion. Some people 
>> (me included) were against, because they disliked the noisiness of “self” 
>> everywhere. Others argued that the implicitness is somewhat unsafe. A valid 
>> position to take. But it’s a kind of thing teams can use a linter for, if 
>> they want to enforce it as a rule.
>> 
>> Trailing closures seem like a similar thing. We could remove it altogether 
>> (although I think that would be a shame), or let’s just leave it up to 
>> preference (and developing guidelines) on where to use them.
>> 
>> Best,
>> — Radek
> 
> Following a style rule is just like using a linter. It's not language 
> mandated and I have not argued for enforcement.
> 
> -- E

Apologies, I didn’t mean to suggest you argued for enforcement. Just adding my 
2¢ about why enforcement makes no sense to me.

Best,
— Radek___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ross O'Brien via swift-evolution]

"or within my whole program (external)". That caused a double-take on its
own.

external things are not within, they are outside. 'external' could be a
replacement term for 'public', not for 'internal'.

This may well be a subjective thing, but I don't think in files, I think in
modules because that's been the default for several years now. If I create
a new type I am implicitly making it visible to everywhere within this
module; it is not outside the module so it is not external. I may then
choose to make it less visible, but it does not 'go inside' when I do this.

If you think in files, I cannot say you are wrong, because it is
subjective. But this is why I have been arguing for non-subjective
keywords. I cannot make 'fileprivate' pretty for you but I do know that
when we both read it we both understand what it means. That's why it hasn't
gone away: it satisfies the criterion of clarity.

Find a pretty alternative with the word 'file' baked into it and I'm with
you.

On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  wrote:

> A new type is implicitly visible *outside* of the file it is defined in
> and hence it is “external” from that point of view. This arrangement seems
> more “human” to me. Someone just learning isn’t going to know about modules
> or how the compiler is treating things anyway and they would almost never
> run into “external” because it’s the default and there’s no reason to
> specify it most of the time. IMO, this “fits” how I think about source code
> while I’m writing it - where do I want to be able to use this symbol?
> Either hidden away and safe (private), inside this file I’m working with
> (internal), or within my whole program (external).
>
> l8r
> Sean
>
>
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien 
> wrote:
> >
> > A new type is implicitly internal to a module. Implicitly specifying it
> as 'external' is just plain confusing.
> >
> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I know this is kind of winding down, and there seems to be a kind of
> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
> but I still really don’t like it so I’m going to toss out my current
> favorite configuration and try to stop caring and defer to the core team to
> make an executive decision so we can all move on with our lives. :P
> >
> > public - unchanged, visible “everywhere"
> > external - visible outside of the file (module, the default)
> > internal - visible only within the file
> > private - visible only within the scope
> >
> > I really like the existing private and I use it a lot to build
> collections of small classes and structs that work together rather than a
> large class/struct that tries to “be everything”. In those scenarios,
> traditional OO private would be too restrictive and even a “protected”
> access type wouldn’t work because I’m trying to avoid building inheritance
> hierarchies. I really need something like “friend” (ugly) or the, imo, much
> more elegant file-scoped access and if that one is renamed “fileprivate”
> I’ll be really sad seeing such an ugly label all over the place. I’d go so
> far as to suggest that an ugly name for this access level would actively
> discourage its use and while some might have that as a goal, to me that
> would encourage the creation of larger “do everything” classes instead of
> clusters of smaller classes and structs and protocols.
> >
> > l8r
> > Sean
> >
> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
> swift-evolution@swift.org> wrote:
> > >
> > >> I’ve seen a number of concerns on this list about moduleprivate, and
> how it penalizes folks who want to explicitly write their access control.
> I’ve come to think that there is yes-another possible path forward here
> (which I haven’t seen mentioned so far):
> > >>
> > >> public
> > >> internal
> > >> fileprivate
> > >> private
> > >>
> > >> The advantages, as I see them are:
> > >> 1) We keep public and private meaning the “right” and “obvious”
> things.
> > >> 2) The declmodifiers “read” correctly.
> > >> 3) Compared to Swift 2, there is almost no change.  The only thing
> that changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> > >> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> > >> 5) The addresses the “excessively long” declmodifier problem that
> several people are concerned with.
> > >> 6) Support for named submodules could be “dropped in” by
> parameterizing “internal”.
> > >>
> > >> Thoughts?
> > >
> > > +1
> > >
> > > Following on from my experience with Delphi adding "strict private"
> for "OO private" members of classes, I would totally agree with your
> proposition.
> > >
> > > Having to use Delphi's "strict private" never really felt right to
> those of us 

Re: [swift-evolution] Enable omitting `let` for constant declarations

[Radosław Pietruszewski via swift-evolution]

I can’t easily find it, but there’s been at least one thread proposing this 
exact thing, and there was very little interest in the proposal.

TL;DR is that Swift *by design* wants to make the difference between these 
three concepts:

- assignment
- declaration of a constant
- declaration of a mutable variable

as explicit and obvious as possible.

— Radek

> On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution 
>  wrote:
> 
> I think it would be good if the following three declarations were equivalent
> 
> let a: Int = 42
> a: Int = 42
> a := 42
> 
> and also the following two were.
> 
> let a: Int
> a: Int
> 
> Then constant declarations become shorter than variable declarations.
> It encourages people to use constants in preference to variables.
> 
> It also prevents repeating `let` for property declarations and makes
> type declarations simpler.
> 
> struct Person {
>firstName: String
>lastName: String
>age: Int
> }
> 
> Omitting `let` is consistent with that we don't write `let` for
> arguments of functions and iterated values in for-in loops.
> 
> Not `=` but `:=` for type inferences because `=` cannot distinguish
> whether it means a constant declaration or an assignment to a variable
> declared in an outer scope. I think `:=` is a natural notation for
> type inferences because omitting the type from `a: Int = 42` makes
> `a:= 42`. Because I have not strictly checked if it can be parsed in
> Swift properly, it may have some other parsing issues.
> 
> What do you think about it?
> 
> -- Yuta
> ___
> 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] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

A new type is implicitly internal to a module. Implicitly specifying it as
'external' is just plain confusing.

On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> I know this is kind of winding down, and there seems to be a kind of
> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
> but I still really don’t like it so I’m going to toss out my current
> favorite configuration and try to stop caring and defer to the core team to
> make an executive decision so we can all move on with our lives. :P
>
> public - unchanged, visible “everywhere"
> external - visible outside of the file (module, the default)
> internal - visible only within the file
> private - visible only within the scope
>
> I really like the existing private and I use it a lot to build collections
> of small classes and structs that work together rather than a large
> class/struct that tries to “be everything”. In those scenarios, traditional
> OO private would be too restrictive and even a “protected” access type
> wouldn’t work because I’m trying to avoid building inheritance hierarchies.
> I really need something like “friend” (ugly) or the, imo, much more elegant
> file-scoped access and if that one is renamed “fileprivate” I’ll be really
> sad seeing such an ugly label all over the place. I’d go so far as to
> suggest that an ugly name for this access level would actively discourage
> its use and while some might have that as a goal, to me that would
> encourage the creation of larger “do everything” classes instead of
> clusters of smaller classes and structs and protocols.
>
> l8r
> Sean
>
> > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> I’ve seen a number of concerns on this list about moduleprivate, and
> how it penalizes folks who want to explicitly write their access control.
> I’ve come to think that there is yes-another possible path forward here
> (which I haven’t seen mentioned so far):
> >>
> >> public
> >> internal
> >> fileprivate
> >> private
> >>
> >> The advantages, as I see them are:
> >> 1) We keep public and private meaning the “right” and “obvious” things.
> >> 2) The declmodifiers “read” correctly.
> >> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> >> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> >> 5) The addresses the “excessively long” declmodifier problem that
> several people are concerned with.
> >> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
> >>
> >> Thoughts?
> >
> > +1
> >
> > Following on from my experience with Delphi adding "strict private" for
> "OO private" members of classes, I would totally agree with your
> proposition.
> >
> > Having to use Delphi's "strict private" never really felt right to those
> of us who were brought up on the OO concept of private, and having
> "private" mean file scope simply encouraged very bad, large, files with
> lots of classes; especially for those who were new to programming.
> >
> > This proposal means that folks coming from other OO languages will
> instantly understand "private"; "fileprivate" does what it says on the tin.
> >
> > To my mind, the only extra scope that might be useful is the OO concept
> of "protected" on a class, but I would like to see a discussion purely
> centred on the effect of more protocols and less class inheritance, with
> its attendant impact on whether protected could also suit extending
> (otherwise private) scope to extensions.
> >
> > In recent experiments of adapting the GOF Design Patterns to Swift, I
> have found using protocols and extensions to greatly reduce the need for
> class inheritance, if not removing the need for classes at all in favour of
> structs.
> >
> > Joanna
> >
> > --
> > Joanna Carter
> > Carter Consulting
> >
> > ___
> > 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] Make optional protocol methods first class citizens

[Sean Heber via swift-evolution]

>> None taken. However, most of the delegate concept of UIKit relies heavily on 
>> this "nonsensical" requirement. It is impossible for someone to implement a 
>> control in swift which is "in the spirit" of UIKit, meaning the control has 
>> a delegate, with several methods that share the same name with different 
>> parameters, some are required and some are optional. I think it is not fair 
>> to tell users that they cannot implement something that is such a common and 
>> repeating pattern in the core. 
> 
> Protocol requirements with default (no-op) implementations already satisfy 
> that design goal, no?
> 
> -Chris

I agree that’s the case, but what happens for situations like UIKit where I do 
not have access to the source? If there is a protocol extension for, say, 
UITableViewDelegate that implements default behaviors, that extension’s 
existence might be publicly declared somewhere so I could know, but the 
implementation bodies would not be, correct? So as a user of 
UITableViewDelegate and without access to UIKit’s source code, I cannot examine 
the protocol extension to see what the extension is *actually* doing by 
default. The situation is then no better than it is now where the information 
about the default behavior or result of a missing delegate function is buried 
somewhere in the documentation. If the protocol spec itself included the 
“effective” default and there was no way to provide a default implementation 
that did anything *except* return a value (or do nothing), then the protocol 
declaration itself documents the intent and I, as an external user of 
UITableViewDelegate without access to the source code, could see exactly what 
it does.

Perhaps my understanding/reasoning there is flawed, but that's why I continue 
to suggest something like this:

protocol MyProtocol {
  default func semiOptionalFunctionA() -> Int = 42  // if unspecified, compiler 
generates implementation that returns 42
  default func semiOptionalFunctionB(thing: Int)   // if unspecified, compiler 
generates implementation that does nothing
  func normalRequiredFunction()   // requires an implementation by the user
}

l8r
Sean

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

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Patrick Gili via swift-evolution]

> 
> What is your evaluation of the proposal?
Anything that increases consistency is good.

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

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

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

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

Quick read.

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

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

[Sean Heber via swift-evolution]

I know this is kind of winding down, and there seems to be a kind of begrudging 
acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still 
really don’t like it so I’m going to toss out my current favorite configuration 
and try to stop caring and defer to the core team to make an executive decision 
so we can all move on with our lives. :P

public - unchanged, visible “everywhere"
external - visible outside of the file (module, the default)
internal - visible only within the file
private - visible only within the scope

I really like the existing private and I use it a lot to build collections of 
small classes and structs that work together rather than a large class/struct 
that tries to “be everything”. In those scenarios, traditional OO private would 
be too restrictive and even a “protected” access type wouldn’t work because I’m 
trying to avoid building inheritance hierarchies. I really need something like 
“friend” (ugly) or the, imo, much more elegant file-scoped access and if that 
one is renamed “fileprivate” I’ll be really sad seeing such an ugly label all 
over the place. I’d go so far as to suggest that an ugly name for this access 
level would actively discourage its use and while some might have that as a 
goal, to me that would encourage the creation of larger “do everything” classes 
instead of clusters of smaller classes and structs and protocols.

l8r
Sean

> On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
>> I’ve seen a number of concerns on this list about moduleprivate, and how it 
>> penalizes folks who want to explicitly write their access control.  I’ve 
>> come to think that there is yes-another possible path forward here (which I 
>> haven’t seen mentioned so far):
>> 
>> public
>> internal
>> fileprivate
>> private
>> 
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) Compared to Swift 2, there is almost no change.  The only thing that 
>> changes is that some uses of Swift 2 “private” will be migrated to 
>> “fileprivate”, which makes the intent of the code much more clear.
>> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
>> modifier, and it would still be “googable”.
>> 5) The addresses the “excessively long” declmodifier problem that several 
>> people are concerned with.
>> 6) Support for named submodules could be “dropped in” by parameterizing 
>> “internal”.
>> 
>> Thoughts?
> 
> +1
> 
> Following on from my experience with Delphi adding "strict private" for "OO 
> private" members of classes, I would totally agree with your proposition.
> 
> Having to use Delphi's "strict private" never really felt right to those of 
> us who were brought up on the OO concept of private, and having "private" 
> mean file scope simply encouraged very bad, large, files with lots of 
> classes; especially for those who were new to programming.
> 
> This proposal means that folks coming from other OO languages will instantly 
> understand "private"; "fileprivate" does what it says on the tin.
> 
> To my mind, the only extra scope that might be useful is the OO concept of 
> "protected" on a class, but I would like to see a discussion purely centred 
> on the effect of more protocols and less class inheritance, with its 
> attendant impact on whether protected could also suit extending (otherwise 
> private) scope to extensions.
> 
> In recent experiments of adapting the GOF Design Patterns to Swift, I have 
> found using protocols and extensions to greatly reduce the need for class 
> inheritance, if not removing the need for classes at all in favour of structs.
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Pelaia II, Tom via swift-evolution]

+1 for this proposal. Seems very reasonable to reduce confusion with very 
little overhead. It would enforce what people should already be doing.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Pelaia II, Tom via swift-evolution]

+1 for this proposal. The resulting code would be clear enough and brings 
benefit.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

> I’ve seen a number of concerns on this list about moduleprivate, and how it 
> penalizes folks who want to explicitly write their access control.  I’ve come 
> to think that there is yes-another possible path forward here (which I 
> haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> changes is that some uses of Swift 2 “private” will be migrated to 
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
> modifier, and it would still be “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several 
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing 
> “internal”.
> 
> Thoughts?

+1

Following on from my experience with Delphi adding "strict private" for "OO 
private" members of classes, I would totally agree with your proposition.

Having to use Delphi's "strict private" never really felt right to those of us 
who were brought up on the OO concept of private, and having "private" mean 
file scope simply encouraged very bad, large, files with lots of classes; 
especially for those who were new to programming.

This proposal means that folks coming from other OO languages will instantly 
understand "private"; "fileprivate" does what it says on the tin.

To my mind, the only extra scope that might be useful is the OO concept of 
"protected" on a class, but I would like to see a discussion purely centred on 
the effect of more protocols and less class inheritance, with its attendant 
impact on whether protected could also suit extending (otherwise private) scope 
to extensions.

In recent experiments of adapting the GOF Design Patterns to Swift, I have 
found using protocols and extensions to greatly reduce the need for class 
inheritance, if not removing the need for classes at all in favour of structs.

Joanna

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Sebastian Hagedorn via swift-evolution]

> What is your evaluation of the proposal?
+1

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

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

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

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

Followed the mailing list thread and read the proposal.


> On 01 Apr 2016, at 05:27, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
> now and runs through April 5, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.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. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>  
> 
> Reply text
> 
> Other replies
>  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 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,
> 
> Doug Gregor
> 
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Sebastian Hagedorn via swift-evolution]

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, it is pretty confusing, especialyl for beginners. I can’t see any benefit 
in the discarded syntax (without dot).

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

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

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read the proposal and followed the mailing list discussion briefly. I’ve also 
noticed the issue in my code.


> On 01 Apr 2016, at 05:41, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance 
> Member Implementations" begins now and runs throughApril 5, 2016. The 
> proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.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. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>  
> 
> Reply text
> 
> Other replies
>  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 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,
> 
> Doug Gregor
> 
> 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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Dave Abrahams via swift-evolution]

Brent Royal-Gordon via swift-evolution  writes:

> A possible mistake in the proposal:

Fixed, thanks!

-Dave

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

Re: [swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Fabian Ehrentraud via swift-evolution]

Great to hear IUOs losing ground :-)

Might adding additional compiler warnings as described in SR-104 accompany the 
implementation of this proposal well?
https://bugs.swift.org/browse/SR-104

Fabian


On 31.03.2016, at 18:43, Chris Lattner via swift-evolution 
> wrote:

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md

The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from Mar 
25…30, 2016. The proposal has been *accepted, pending implementation 
experience*:

There is generally positive feedback on the proposal, as it keeps the good 
behaviors of the existing T! type syntax (including support for importing 
un-nullability-audited APIs, support for 2-phase initialization patterns, etc) 
while dramatically reducing the confusion and surprise that they introduce as 
they trickle through type inference.  The core team sees significant value in 
having a simple and predictable model that can be explained concisely.

That said, this is the sort of proposal that can have a profound impact on the 
actual experience using unaudited APIs.  The core team believes that the 
experience will be good, but we would like to get some experience moving a 
couple of existing projects (both low-level code that interacts with C, and an 
“App” project working with high level frameworks) to see what the impact is in 
practice.  If something unexpected comes up, we will revisit this, and 
potentially reject it later.  Chris Willmore is working on an implementation of 
this now, so we should know in the next week or two.

Thank you to Chris Willmore for driving this forward!

-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