[swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

[Tim Vermeulen via swift-evolution]

This is a follow up from this swift-users thread: 
https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html

As it stands, RangeReplaceableCollection requires an implementation for init(), 
which is used in the default implementations of (as far as I can tell) 
init(_:), init(repeating:count:) and removeAll(keepingCapacity:). The latter of 
these methods should be implementable with removeSubrange(_:) instead.

I would like to propose to *remove* all three initialisers from this protocol, 
because it makes it impossible for some collections to conform to it that need 
extra data for its initialisation, but are otherwise perfectly capable of 
having arbitrary subranges replaced by elements from another collection. Those 
three initialisers could either move to a new protocol or simply not be part of 
any protocol.

On a similar note, I’d like to have all initialisers of SetAlgebra removed as 
well, but that might need its own review.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> If you have a ParentClass and a SubClass, and the ParentClass is sealed 
>> while the SubClass is subclassable. What happens? No matter how this 
>> question is answered, I don't like the answer. (compile error => bad. || 
>> make it as the user wishes => bad; what do we gain by letting ParentClass 
>> remain sealed? || make ParentClass implicitly subclassable too => bad.)
> I'm happy that there are not only supporters for this proposal, but imho the 
> example is no compelling argument:
> With no doubt, I'd expect I can subclass only SubClass — like I can't 
> instantiate an abstract class, which is just fine for its children.
> ParentClass might do some dangerous things that don't happen in SubClass, so 
> there might even be a use-case (but imho it would be better if I could mark 
> ParentClass as internal in this situation).
> 
> But imho there is another aspect I haven't read about yet:
> "final by default" would have had direct impact on any developer, while this 
> proposal merely changes things for those who create libraries…
> So, the question is: How will those be build?
> 
> If you live in a world of secrets and non-disclosure, I can understand that 
> sealed is desirable — but that's not the future I want to see, and github is 
> a good indication that others share this opinion.
> 
> If you share the sympathy for Open source, the two scenarios are as follows:
> We stick with "open by default"; users of libraries will use them in ways 
> that the creator hasn't thought of before, and bugs will show up.
> But: We know how to deal with bugs, that's our job! So in the best case, we 
> find the reason for the bad behavior, create a pull request, and everyone is 
> happy.
> 
> With "sealed by default", the situation changes:
> Users are protected from some simple bugs, but nonetheless, they'll encounter 
> situations where the library doesn't do exactly what they want.
> So, you take a look at the source, find the problem, and fix it.
> It's no bug at all, it's just a tiny degree of freedom that is missing 
> because it wasn't important to the author.
> You can create a pull request as well, but it doesn't offer a real 
> improvement to the author, who is already busy with dozens of similar 
> requests by other users -> you end up with a custom branch with all the 
> housekeeping associated with it.
> 
> So overall, I'm quite sure that the proposal won't improve software quality, 
> but rather degrade it.

:) 

> Tino
> ___
> 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] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

[Charlie Monroe via swift-evolution]

> On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> 
>> * Remove unsafeAddressOf. "We are not aware of any real use cases for it. If 
>> there are any, it should be renamed to unsafeAddress(of:) to follow the 
>> guidelines." (https://bugs.swift.org/browse/SR-1957 
>>  rdar://problem/18589289 <>)
>> 
>> 
>> Oops, I just responded to this on another thread. Pasting:
>> 
>> It's minor, but I use unsafeAddressOf regularly for writing `description` 
>> methods:
>> 
>> var description: String {
>> return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info 
>> here... }"
>> }
>> 
>> I guess this would be covered by some generalized solution for format 
>> specifiers in string interpolations, but I gather that won't happen for 
>> quite a while... 
> 
> I believe `ObjectIdentifier(self)` prints basically the same way.
> 
> Jordan

Unfortunately, it doesn't:

print("\(ObjectIdentifier(obj))")

--> ObjectIdentifier(_value: (Opaque Value))




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

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Charlie Monroe via swift-evolution]

> On Jul 7, 2016, at 1:10 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> In the motivation section performance is also mentioned as driving this 
> proposal. However I don't see any study that supports that. I would like to 
> see that. This should not be taken lightly. 

There kind of was a discussion on this.

John McCall (http://article.gmane.org/gmane.comp.lang.swift.evolution/22111 
)

> Finally, the specific form of devirtualization in question here, where a 
> method is proven to never be overridden (again, very common for accessors!), 
> can have a significant impact separate from any calls because the method 
> essentially no longer needs to be virtual.  That is, it can be removed from 
> the virtual method tables completely, and we may be able to completely avoid 
> emitting it.  That shrinks the size of global memory (and the binary), 
> decrease the amount of work that has to be done at load-time, and improves 
> locality within the virtual table.


I remember that he's mentioned some benchmark final vs. non-final where the 
difference was in some cases staggering. In general, when you enable 
whole-module optimization, the compiler can treat all classes within the module 
as final and optimize mainly accessing properties since they are then known to 
be final...



> 
> Let's imagine that performance is important for a library that is heavily 
> used and that the classes are not the type that you usually override. 
> Wouldn't we be better served  by being able to seal the class, i.e. "public 
> sealed class Foo"  and then for the methods / properties that are clear 
> extension points should be flagged overridable.  I would prefer something 
> like that. And I think it would be more intuitive. 
> 
> 
>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> No. 
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> I think it is counter-intuitive. I don't think that reading "public class 
> Foo" would make anyone think that Foo is non-subclassable. 
> 
> On the other hand, reading "public class sealed Foo" would suggest to the 
> reader that the class can be overridden but only the methods that are flagged 
> as overridable. 
> 
> If we wanted to prohibit overriding then we could use "public final class 
> Foo" without any extension points. Then nobody would be able to subclass and 
> it would be an error to try to flag a method / property as overridable.  
> 
> 
>>* If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I don't recall having seen this behavior in the languages that I have worked 
> with. 
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I read the whole proposal and have been thinking about the implications for a 
> few hours. 
> 
>> More information about the Swift evolution process is available at
>> 
>>https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

I'd rather like

let bar = foo as (a:c:)

to limit the possibility of bar not uncleared way. 
> 
>> 在 2016年7月7日，12:11，Félix Cloutier  写道：
>> 
>> I personally find that { foo(a: $0, c: $1) } is an already simple enough way 
>> to solve that problem.
>> 
>> Félix
>> 
>>> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution 
>>>  a écrit :
>>> 
>>> l'd like the way of Python to handle the function signature.Assign lost 
>>> other possibility of that function:
>>> 
>>> foo(b:c:)
>>> foo(a:c:)
>>> foo(a:b:)
>>> foo(a:)
>>> foo(b:)
>>> foo(c:)
>>> foo()
>>> 
>>> very weird.
>>> 
>>> 
>>> 
> 在 2016年7月7日，11:36，Douglas Gregor  写道：
> 
> 
> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote:
> 
> so how you call bar and get default values for a, b, c?
 
 You don’t.
 
> why lost default value for that function? it is wired.
 
 Default values aren’t part of a function type. While it is possible to 
 come up with such designs, there is little precedent for them and doing so 
 either drastically limits what kinds of default arguments can be expressed 
 or causes values of function type to become large (so they can encode the 
 computation of the default values).
 
   - Doug
 
> 
>>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>>> 
>>> 
>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>>>  wrote:
>>> 
>>> Don't agree with this one.
>>> 
>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>> print(a, b, c)
>>> }
>>> 
>>> foo(a: 1, c: 3)
>>> 
>>> let bar = foo
>>> 
>>> bar(1, 3) will different than foo(a: 1, c: 3)
>> 
>> bar(1, 3) will result in an error, because “bar” is of type 
>> 
>> (Int, Int, Int) -> Void
>> 
>> Default arguments are associated with function declarations, not 
>> function types.
>> 
>> - Doug
>> 
>> 
>>> 
 在 2016年7月7日，11:06，Chris Lattner  写道：
 
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
 
 The review of "SE-0111: Remove type system significance of function 
 argument labels " ran from June 30 ... July 4, 2016. The proposal has 
 been *accepted*:
 
 The community and core team agree that this proposal will lead to a 
 simplification and clarification of the type system, as well as a more 
 clear user model for parameter labels.  In response to community 
 feedback, the core team is accepting the proposal with a revision to 
 allow “purely cosmetic” parameter labels in closure types for 
 documentation (as outlined in the alternatives section).  The core 
 team also wants to clarify that a call to a value of closure type 
 would not allow use of any parameter labels, some interpretations 
 thought that “arbitrary” parameter labels could be used.
 
 Thank you to Austin Zheng for driving this discussion forward!  I 
 filed SR-2009 to track implementation work on this.
 
 -Chris Lattner
 Review Manager
 
 ___
 swift-evolution-announce mailing list
 swift-evolution-annou...@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
 
>>> 
>>> 
>>> ___
>>> swift-evolution 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] [Accepted] SE-0113: Add integral rounding functions to FloatingPoint

[Chris Lattner via swift-evolution]

> On Jul 6, 2016, at 9:16 PM, Pyry Jahkola  wrote:
> 
> I think one more thing needs clarification. Shouldn't the "defaulted" 
> `rounded()` and `round()` be defined as protocol extension methods *without* 
> the possibility to override the default rounding mode in a conforming type? 
> Like so:
> 
>public protocol FloatingPoint {
>  ...
>  func rounded(_ rule: RoundingRule) -> Self
>  mutating func round(_ rule: RoundingRule)
>}
> 
>public extension FloatingPoint {
>  public func rounded() -> Self {
>return rounded(.toNearestOrAwayFromZero)
>  }
>  public mutating func round() {
>round(.toNearestOrAwayFromZero)
>  }
>}
> 
> I would find it quite surprising if some type conforming to FloatingPoint 
> rounded differently by default than the others.

Yes good point.  That is my mistake summarizing the discussion of the core team 
today.  This is indeed how it should be structured.

-Chris


> 
> — Pyry
> 
>> Chris Lattner wrote:
>> 
>> Since protocol requirements cannot currently have default arguments, the 
>> desired behavior should be achieved with two overloads of each operation:
>> 
>> protocol FloatingPoint {
>> ...
>> /// Returns a rounded representation of `self`, according to the specified 
>> rounding rule.
>> func rounded() -> Self
>> func rounded(_ rule: RoundingRule) -> Self
>> 
>> /// Mutating form of `rounded`.
>> mutating func round()
>> mutating func round(_ rule: RoundingRule)
>> }
>> 
>> Where the no argument cases can be implemented with a protocol extension 
>> that forwards to the single-argument versions.

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

Re: [swift-evolution] [Accepted] SE-0113: Add integral rounding functions to FloatingPoint

[Pyry Jahkola via swift-evolution]

I think one more thing needs clarification. Shouldn't the "defaulted" 
`rounded()` and `round()` be defined as protocol extension methods *without* 
the possibility to override the default rounding mode in a conforming type? 
Like so:

public protocol FloatingPoint {
  ...
  func rounded(_ rule: RoundingRule) -> Self
  mutating func round(_ rule: RoundingRule)
}

public extension FloatingPoint {
  public func rounded() -> Self {
return rounded(.toNearestOrAwayFromZero)
  }
  public mutating func round() {
round(.toNearestOrAwayFromZero)
  }
}

I would find it quite surprising if some type conforming to FloatingPoint 
rounded differently by default than the others.

— Pyry

> Chris Lattner wrote:
> 
> Since protocol requirements cannot currently have default arguments, the 
> desired behavior should be achieved with two overloads of each operation:
> 
> protocol FloatingPoint {
>  ...
>  /// Returns a rounded representation of `self`, according to the specified 
> rounding rule.
>  func rounded() -> Self
>  func rounded(_ rule: RoundingRule) -> Self
> 
>  /// Mutating form of `rounded`.
>  mutating func round()
>  mutating func round(_ rule: RoundingRule)
> }
> 
> Where the no argument cases can be implemented with a protocol extension that 
> forwards to the single-argument versions.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Brad Hilton via swift-evolution]

I completely agree with rparada and give a strong, strong, strong -1 to this 
proposal. To make classes non-subclassable by default is only going to lead to 
unanticipated pain and frustration. Also agree with other comments that 
subclassable and overridable conflate access control with class behavior. If we 
want to make it possible to define a class as non-subclassable to external 
users, I’d agree to something more consistent with existing swift access 
control like public(final) as has been proposed by other commenters. However, I 
agree that making classes final by default is a bad idea that will create a 
larger problem that it solves.

Also, just a more general complaint, I sometimes feel that the evolution list 
is being dominated by safety enthusiasts at the expense of usability advocates. 
Safety is a premier feature of Swift, but so is usability. We should be trying 
to find solutions that advance both objectives, as well as performance and 
power.

> On Jul 5, 2016, at 7:11 PM, Chris 
> Lattnerwrote:
> 
> > Hello Swift community,
> > 
> > The review of "SE-0117: Default classes to be non-subclassable publicly" 
> > begins now and runs through July 11. The proposal is available here:
> > 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> > 
> > * What is your evaluation of the proposal?
> -1
> 
> Perhaps because this is so different from what I have seen in other languages 
> and used for so many years. I have not worked with a language that uses 
> non-subclassable/ non-overridable as the default.
> 
> I think that by default classes should be subclassable, not the other way 
> around. I am afraid that developers will not take the time to specify which 
> methods are overridable resulting in libraries that are difficult to patch, 
> extend.
> 
> In my 26+ years of object-oriented design and programming (other languages, 
> Objective-C since 1990 and Java since 2001) I have worked with object 
> oriented libraries and subclassed methods that the authors probably never 
> anticipated. I have been able to fix problems, enhance classes by creating 
> subclasses with fixes and enhanced behavior.
> 
> In java for example I have seen that sometimes I would have been able to fix 
> bugs or enhance the existing classes had the author not chosen a method to be 
> protected or private. Sometimes they had a good reason but sometimes they 
> didn't.Is have been able to survive using an awesome library that was 
> discontinued and end-of-lifed thanks to subclassing that has allowed me to 
> fix problems and enhance over the years as the Java language kept evolving.
> 
> In general I like to design classes with methods that have a very well 
> defined purpose / logic. Such methods are potentially overridable. I find 
> that making a method private or final can be selfish / restrictive at times 
> and I choose it carefully for implementation details that are better served 
> by going through the public methods.
> 
> I think that making a class not subclassable by default is restrictive / 
> limiting / selfish.
> 
> Sometimes the extension points are clear.
> I also think that every other method with a well defined purpose / logic is 
> also potentially an extension point.
> 
> In my experience we should allow the developer to override by default.That is 
> how I design my classes and every method / property.
> 
> I use private for the stuff that is obvious that should not be exposed.
> 
> In the motivation sectionperformanceis also mentioned as driving this 
> proposal. However I don't see any study that supports that. I would like to 
> see that. This should not be taken lightly.
> 
> Let's imagine that performance is important for a library that is heavily 
> used and that the classes are not the type that you usually override. 
> Wouldn't we be better servedby being able to seal the class, i.e. "public 
> sealed class Foo"and then for the methods / properties that are clear 
> extension points should be flaggedoverridable.I would prefer something like 
> that. And I think it would be more intuitive.
> 
> 
> > * Is the problem being addressed significant enough to warrant a change to 
> > Swift?
> No.
> 
> > * Does this proposal fit well with the feel and direction of Swift?
> I think it is counter-intuitive.I don't think that reading "public class Foo" 
> would make anyone think that Foo is non-subclassable.
> 
> On the other hand, reading "public class sealed Foo" would suggest to the 
> reader that the class can be overridden but only the methods that are flagged 
> asoverridable.
> 
> If we wanted to prohibit overriding then we could use "public final class 
> Foo" without any extension points. Then nobody would be able to subclass and 
> it would be an error to try to flag a method / property as overridable.
> 
> 
> > * If you have used other languages or libraries with a similar feature, how 

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Félix Cloutier via swift-evolution]

I personally find that { foo(a: $0, c: $1) } is an already simple enough way to 
solve that problem.

Félix

> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution 
>  a écrit :
> 
> l'd like the way of Python to handle the function signature.Assign lost other 
> possibility of that function:
> 
> foo(b:c:)
> foo(a:c:)
> foo(a:b:)
> foo(a:)
> foo(b:)
> foo(c:)
> foo()
> 
> very weird.
> 
> 
> 
>> 在 2016年7月7日，11:36，Douglas Gregor  写道：
>> 
>> 
>>> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote:
>>> 
>>> so how you call bar and get default values for a, b, c?
>> 
>> You don’t.
>> 
>>> why lost default value for that function? it is wired.
>> 
>> Default values aren’t part of a function type. While it is possible to come 
>> up with such designs, there is little precedent for them and doing so either 
>> drastically limits what kinds of default arguments can be expressed or 
>> causes values of function type to become large (so they can encode the 
>> computation of the default values).
>> 
>>   - Doug
>> 
>>> 
 在 2016年7月7日，11:29，Douglas Gregor  写道：
 
 
> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>  wrote:
> 
> Don't agree with this one.
> 
> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
> print(a, b, c)
> }
> 
> foo(a: 1, c: 3)
> 
> let bar = foo
> 
> bar(1, 3) will different than foo(a: 1, c: 3)
 
 bar(1, 3) will result in an error, because “bar” is of type 
 
 (Int, Int, Int) -> Void
 
 Default arguments are associated with function declarations, not function 
 types.
 
 - Doug
 
 
> 
>> 在 2016年7月7日，11:06，Chris Lattner  写道：
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>> 
>> The review of "SE-0111: Remove type system significance of function 
>> argument labels " ran from June 30 ... July 4, 2016. The proposal has 
>> been *accepted*:
>> 
>> The community and core team agree that this proposal will lead to a 
>> simplification and clarification of the type system, as well as a more 
>> clear user model for parameter labels.  In response to community 
>> feedback, the core team is accepting the proposal with a revision to 
>> allow “purely cosmetic” parameter labels in closure types for 
>> documentation (as outlined in the alternatives section).  The core team 
>> also wants to clarify that a call to a value of closure type would not 
>> allow use of any parameter labels, some interpretations thought that 
>> “arbitrary” parameter labels could be used.
>> 
>> Thank you to Austin Zheng for driving this discussion forward!  I filed 
>> SR-2009 to track implementation work on this.
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> 
>>> 
>> 
> 
> 
> ___
> swift-evolution 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] Dropping Comparable requirement for indices

[David Sweeris via swift-evolution]

> On Jul 6, 2016, at 20:41, Dave Abrahams via swift-evolution 
>  wrote:
> 
> There is no way, AFAIK, to implement important algorithms like rotate
> binarySearch and several others, without having some representation of
> position within a collection.

Do you need indices to be explicitly comparable for that, or will simply being 
able to test for equality and being within a "range" work? I realize that in 
most cases, testing an index for being in a range implies comparable, but what 
about multi-dimensional indices? Comparison isn't well defined for, say, 2D 
points, but in theory all the points within a circle or something  could be the 
indices for something.

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

l'd like the way of Python to handle the function signature.Assign lost other 
possibility of that function:

foo(b:c:)
foo(a:c:)
foo(a:b:)
foo(a:)
foo(b:)
foo(c:)
foo()

very weird.



> 在 2016年7月7日，11:36，Douglas Gregor  写道：
> 
> 
>> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote:
>> 
>> so how you call bar and get default values for a, b, c?
> 
> You don’t.
> 
>> why lost default value for that function? it is wired.
> 
> Default values aren’t part of a function type. While it is possible to come 
> up with such designs, there is little precedent for them and doing so either 
> drastically limits what kinds of default arguments can be expressed or causes 
> values of function type to become large (so they can encode the computation 
> of the default values).
> 
>- Doug
> 
>> 
>>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>>> 
>>> 
 On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
  wrote:
 
 Don't agree with this one.
 
 func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
 print(a, b, c)
 }
 
 foo(a: 1, c: 3)
 
 let bar = foo
 
 bar(1, 3) will different than foo(a: 1, c: 3)
>>> 
>>> bar(1, 3) will result in an error, because “bar” is of type 
>>> 
>>>  (Int, Int, Int) -> Void
>>> 
>>> Default arguments are associated with function declarations, not function 
>>> types.
>>> 
>>>  - Doug
>>> 
>>> 
 
> 在 2016年7月7日，11:06，Chris Lattner  写道：
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
> 
> The review of "SE-0111: Remove type system significance of function 
> argument labels " ran from June 30 ... July 4, 2016. The proposal has 
> been *accepted*:
> 
> The community and core team agree that this proposal will lead to a 
> simplification and clarification of the type system, as well as a more 
> clear user model for parameter labels.  In response to community 
> feedback, the core team is accepting the proposal with a revision to 
> allow “purely cosmetic” parameter labels in closure types for 
> documentation (as outlined in the alternatives section).  The core team 
> also wants to clarify that a call to a value of closure type would not 
> allow use of any parameter labels, some interpretations thought that 
> “arbitrary” parameter labels could be used.
> 
> Thank you to Austin Zheng for driving this discussion forward!  I filed 
> SR-2009 to track implementation work on this.
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 
> 


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

[swift-evolution] [Accepted] SE-0113: Add integral rounding functions to FloatingPoint

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

The review of "SE-0113: Add integral rounding functions to FloatingPoint " ran 
from June 30 ... July 5, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal helps to “round out" the 
other Swift 3 numerics work.  One minor revision is necessary to make the 
proposal implementable in Swift 3.  Since protocol requirements cannot 
currently have default arguments, the desired behavior should be achieved with 
two overloads of each operation:

protocol FloatingPoint {
  ...
  /// Returns a rounded representation of `self`, according to the specified 
rounding rule.
  func rounded() -> Self
  func rounded(_ rule: RoundingRule) -> Self

  /// Mutating form of `rounded`.
  mutating func round()
  mutating func round(_ rule: RoundingRule)
}

Where the no argument cases can be implemented with a protocol extension that 
forwards to the single-argument versions.

Thank you to Karl Wagner for driving this discussion forward!  I filed SR-2010 
to track implementation work on this.

-Chris Lattner
Review Manager

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

[swift-evolution] Fwd: [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[Cao, Jiannan via swift-evolution]

so how you call bar and get default values for a, b, c? why lost default value 
for that function? it is wired.
> 
>> 在 2016年7月7日，11:29，Douglas Gregor  写道：
>> 
>> 
>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution 
>>>  wrote:
>>> 
>>> Don't agree with this one.
>>> 
>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>>  print(a, b, c)
>>> }
>>> 
>>> foo(a: 1, c: 3)
>>> 
>>> let bar = foo
>>> 
>>> bar(1, 3) will different than foo(a: 1, c: 3)
>> 
>> bar(1, 3) will result in an error, because “bar” is of type 
>> 
>>   (Int, Int, Int) -> Void
>> 
>> Default arguments are associated with function declarations, not function 
>> types.
>> 
>>   - Doug
>> 
>> 
>>> 
 在 2016年7月7日，11:06，Chris Lattner  写道：
 
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
 
 The review of "SE-0111: Remove type system significance of function 
 argument labels " ran from June 30 ... July 4, 2016. The proposal has been 
 *accepted*:
 
 The community and core team agree that this proposal will lead to a 
 simplification and clarification of the type system, as well as a more 
 clear user model for parameter labels.  In response to community feedback, 
 the core team is accepting the proposal with a revision to allow “purely 
 cosmetic” parameter labels in closure types for documentation (as outlined 
 in the alternatives section).  The core team also wants to clarify that a 
 call to a value of closure type would not allow use of any parameter 
 labels, some interpretations thought that “arbitrary” parameter labels 
 could be used.
 
 Thank you to Austin Zheng for driving this discussion forward!  I filed 
 SR-2009 to track implementation work on this.
 
 -Chris Lattner
 Review Manager
 
 ___
 swift-evolution-announce mailing list
 swift-evolution-annou...@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 


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

[swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument 
labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a 
simplification and clarification of the type system, as well as a more clear 
user model for parameter labels.  In response to community feedback, the core 
team is accepting the proposal with a revision to allow “purely cosmetic” 
parameter labels in closure types for documentation (as outlined in the 
alternatives section).  The core team also wants to clarify that a call to a 
value of closure type would not allow use of any parameter labels, some 
interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward!  I filed SR-2009 
to track implementation work on this.

-Chris Lattner
Review Manager

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

[swift-evolution] [Accepted] SE-0110: Distinguish between single-tuple and multiple-argument function types

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

The second review of "SE-0110: Distinguish between single-tuple and 
multiple-argument function types " ran from June 30 ... July 4, 2016. The 
proposal has been *accepted*:

The community and core team agree that this proposal is the right thing to do, 
and many agree that this could probably have been treated as a bug fix on a 
previous proposal.

Thank you to Vladimir S. and Austin Zheng for driving this discussion forward!  
I filed SR-2008 to track implementation work on this, this would be a great 
area for someone interested in the type checker to dive into the Swift compiler.

-Chris Lattner
Review Manager

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

[swift-evolution] [Rejected] SE-0108: Remove associated type inference

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md

The second review of "SE-0108: Remove associated type inference" ran from June 
29 ... July 4, 2016. The proposal has been *rejected*:

The community and core team agree that removing this feature will impose an 
unacceptable user experience regression for developers using Swift generics, 
including important protocols like Collection.  While we all seek the 
simplifications to the compiler internals that the proposal would allow, we 
will have to consider other approaches to achieving that in subsequent releases.

Thank you to Douglas Gregor and Austin Zheng for driving this discussion 
forward!

-Chris Lattner
Review Manager

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

Re: [swift-evolution] Dropping Comparable requirement for indices

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Haravikk  wrote:

>> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution 
>>  wrote:
>> For example, with
>> Comparable indices, you can't build a linked list that supports
>> restructuring (e.g. insert, delete, splice) in O(1) without invalidating
>> indices... not even an unsafe linked list with reference semantics.
>
> I think the question is why you need to retain indices in these cases?
>
> When it comes to these operations I wonder if we might want to
> investigate something like a mutating iterator; you might still use an
> index to jump to an initial position, but then use .insert(),
> .remove() etc. methods of the iterator to perform modification without
> the need to track indices at all. 

There is no way, AFAIK, to implement important algorithms like rotate
binarySearch and several others, without having some representation of
position within a collection.

> This is essentially how you want to edit trees anyway, as indexing
> them isn't especially pretty, as it avoids the need to track the
> indices at all for these operations, and many common cases should work
> well when done as part of an iterator in this way.

I don't know what you mean by “track,” here.  We don't track the
indices of an array.

-- 
Dave

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

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Dave Abrahams via swift-evolution]

on Tue Jul 05 2016, Dmitri Gribenko  wrote:

> On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner  wrote:
>> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>>>
>>> Hi swift-evolution,
>>>
>>> Dave, Max and I have compiled a list of open issues in the standard
>>> library for which the resolutions could result non-additive API
>>> changes.  Having a resolution (and an implementation of the
>>> resolution!) for these issues is blocking API stability.
>>>
>>> https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d
>>
>> Thank you for collecting this Dmitri!  For the issues in the “low
>> hanging fruit” list, are the changes all sufficiently "obvious”?  If
>> so, having one proposal tackle all of them in one sweep would be
>> preferable to reduce process overhead.
>
> My subjective assessment:
>
>> The global function withUnsafe[Mutable]Pointer() should have an argument 
>> label “to”.
> Obvious.
>
>> UnicodeScalar.init(Int) should be failable.
> Obvious.
>
>> withUnsafePointer shouldn't take its argument as inout.
> Jordan has objections, see https://bugs.swift.org/browse/SR-1956
>
>> Remove unsafeAddressOf. We are not aware of any real usecases for
>> it. If there are any, it should be renamed to unsafeAddress(of:) to
>> follow the guidelines.
> Obvious, unless someone comes up with use cases during the review period.
>
>> Consider renaming or eliminating ManagedProtoBuffer.
>> The reason why ManagedProtoBuffer exists is to give the users an
>> extra bit of type safety inside of the closure passed to
>> ManagedBuffer.create().
> Debatable.

The only debate, IMO, is whether to rename or eliminate.  Anything with
“ProtoBuf” in the name is likely to be misleading.

>> String.CharacterView.Iterator should be a custom type rather than
>> the default, to allow performance optimizations. Audit all other
>> collections for such opportunities.
> Obvious.
>
>> String(count:, repeatedValue:) and String.append() are ambiguous without an 
>> explicit cast to Character.
> Obvious.
>
>> Rename the ~LiteralConvertible protocols according to the resolution of the 
>> proposal currently under review.
> A separate review.
>
> Dmitri

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, David Rönnqvist  wrote:

>>* What is your evaluation of the proposal?
>
> +1. These look like good improvements to me. (I'm also happy that the 
> map/filter/reduce naming was left out of this proposal)
>
> One thing I was wonder about was the capitalization of UTF8 in the
> first example. Shouldn't that be s.withUTF8Buffer(processBytes)instead
> of s.withUtf8Buffer(processBytes) or am I confusing Swift's
> conventions with Cocoa's?

No, you're right; fixed, thanks!

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Kevin Lundberg via swift-evolution]

On 7/6/2016 1:52 AM, Chris Lattner wrote:

>> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution 
>>  wrote:
>>
>> * What is your evaluation of the proposal?
>>
>> -1 as is. I do not want to be constrained by authors of libraries or
>> frameworks into interacting with a system in only the ways they forsee.
>> By making the default be non-subclassable, if a designer does not put
>> thought into all the ways a class can be used then I as a consumer of
>> the library am penalized.
> Out of curiosity, what is your feeling about “internal” as the default level 
> of access control?  It seems that following your concern to its logical 
> conclusion would lead to a design where all members of a public class would 
> be forced to be public.  After all, the author of a library or framework may 
> not forsee the need to interact with a member that they did not explicitly 
> mark public.
>
> -Chris

I can appreciate this argument, but I would hope that my viewpoint is a
bit more nuanced than that :). To turn the tables a bit, one could argue
that, taken to the proposal's logical conclusion, writable properties
should not be publicly writable for safety's sake. Instead, they should
be required to be explicitly marked as publicly settable if needed as it
should be up to the author of that type to carefully consider how safe
it is for others to mutate the state of their types. Yet today both
sides of a property are given the same access level unless one
explicitly restricts the visibility of it's setter. The current behavior
(of properties specifically, and the access control feature as a whole)
achieves a balance of convenience, power, and safety that I am happy with.

The proposed change however sacrifices too much convenience for a
greater sense of safety and control by default. It's not possible to
accidentally override a method like it is in java or objective-c, so the
proposal won't help people who might accidentally override something. If
a developer tries to override a method or class they probably have a
specific reason in mind for doing so, and taking away the options that
this ability presents, by nature of it being the default behavior,
doesn't sit well with me as it has the potential to take away a good
tool from my toolbox.

I agree that API authors should have the power to restrict this
dimension of a type's usage, but I feel that it should be a conscious
choice to do so.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Felipe Cypriano via swift-evolution]

Strong +1 for me, separating access control from "open-to-subclasses" is
a great feature. Leonardo's example of why final is not enough is great.
 
My stance is that Swift should be safe by default, predictable, and the
compiler should know enough about the code to actually help me and this
proposal fits this.
 
About testability, I don't think we should downplay how to test "sealed"
classes from outside the framework. I do agree that the class should be
treated as a black box with only public APIs available, but testing how
my app is using those APIs  should be possible somehow.
 
Last but not least, I don't like the proposed subclassable/overridable,
specially because they imply public.
 
 
On Wed, Jul 6, 2016, at 12:35, Leonardo Pessoa via swift-evolution wrote:
> Intention.
>
> IMO, intention may lead to more secure systems (and libraries). By
> having to explicitly final everything I have to choose with parts of
> my class/library would be locked and have to worry and check if any
> public thing could be used to exploit it or make the system work in a
> way I did not intended to. Also, final will prevent anyone including
> me from extending/overriding. Defaulting to final would require from
> me to explicitly declare the open endpoints in my libraries, so I
> could explicitly open only the ones that are really intended to be
> used in that way by third-parties.
>
> As an example, I'm working on a system which has an internal
> representation of Files and Folders using a common superclass (lets
> call it Entry). I would like for other developers to be able to create
> new entry types (not only inheriting from File) but I do not wish for
> them to extend from Folder or any of its subclasses (specialised
> folders). By using final I can prevent others from extending my Folder
> but I cannot extend it myself and thus need another mechanism for
> achieving this behaviour without bloating the Folder class with all
> its specialisations. This proposal would allow me to make my Folder
> and its subclasses publicly available/usable but would prevent others
> from subclassing and thus misusing them in ways I did not intend them
> to. The same rationale applies to methods.
>
> L
>
> On 6 July 2016 at 16:09, Goffredo Marocchi  wrote:
>> Leonardo, how is defaulting to final/sealed helping you write better
>> libraries than having a final keyword for what you need to close
>> instead?
>>
>> Sent from my iPhone
>>
>> On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution > evolut...@swift.org> wrote:
>>
 The review of "SE-0117: Default classes to be non-subclassable
 publicly" begins now and runs through July 11. The proposal is
 available here:

 https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md

   * What is your evaluation of the proposal?
>>>
>>> +1. Being able to control how a class from my libraries are going to
>>> be used by third-parties could enable a better designed API
>>> with more
>>> control of how it is intended to be used. I'm just not fond of using
>>> the proposed keywords ('subclassable' and 'overridable') as
>>> they feel
>>> more like protocol or attribute names; I'd be more inclined to
>>> use the
>>> alternative 'public open' instead, or 'public(open)' as a second
>>> option.
>>>
   * Is the problem being addressed significant enough to
 warrant a change to Swift?
>>>
>>> I'd say it is significant to every language.
>>>
   * 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?
>>>
>>> C# uses the keyword 'virtual' to explicitly mark methods that can be
>>> overriden (not considered in the alternatives but I'm not a big
>>> fan of
>>> it).
>>>
   * How much effort did you put into your review? A glance, a
 quick reading, or an in-depth study?
>>>
>>> I've took (a small) part on the thread discussing this proposal but
>>> followed it closely
>>> _
>>> 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] Removing Variadic Parameters.

[Rob Mayoff via swift-evolution]

On Wed, Jul 6, 2016 at 2:57 PM, Tino Heth via swift-evolution
 wrote:
> Can you talk about concrete examples? Because Objective-C had no variadic 
> messages, it's natural that the feature isn't utilized in Cocoa

Objective-C has variadic messages. I'd be surprised if any seasoned
Objective-C developer hasn't used `+[NSString stringWithFormat:]`.

These are most of the variadic messages in the El Capitan SDK:

-[NSGradient initWithColorsAndLocations:]
-[AMAction logMessageWithLevel:format:]
-[CIFilter apply:]
+[CISampler samplerWithImage:keysAndValues:]
-[CISampler initWithImage:keysAndValues:]
+[NSArray arrayWithObjects:]
-[NSArray initWithObjects:]
-[NSCoder encodeValuesOfObjCTypes:]
-[NSCoder decodeValuesOfObjCTypes:]
+[NSDictionary dictionaryWithObjectsAndKeys:]
-[NSDictionary initWithObjectsAndKeys:]
+[NSException raise:format:]
-[NSException handleFailureInMethod:object:file:lineNumber:description:]
-[NSException handleFailureInFunction:file:lineNumber:description:]
+[NSExpression expressionWithFormat:]
+[NSOrderedSet orderedSetWithObjects:]
-[NSOrderedSet initWithObjects:]
+[NSPredicate predicateWithFormat:]
+[NSSet setWithObjects:]
-[NSSet initWithObjects:]
-[NSString stringByAppendingFormat:]
-[NSString initWithFormat:]
-[NSString initWithFormat:locale:]
+[NSString stringWithFormat:]
+[NSString localizedStringWithFormat:]
-[NSString appendFormat:]
-[SBObject  sendEvent:id:parameters:]
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Karl via swift-evolution]

> On 7 Jul 2016, at 03:15, Karl  wrote:
> 
> 
>> On 7 Jul 2016, at 02:06, Dmitri Gribenko > > wrote:
>> 
>> On Wed, Jul 6, 2016 at 4:21 AM, Karl > > wrote:
>>> I had a PR open for this which added a Collection specialisation, but you
>>> said this could be handled in a more general way which allows for more
>>> optimised mutations. I’m curious how this would work; how does
>>> `RangeReplaceableCollection.replaceSubrange(range:, with: S)`
>>> call a more optimised implementation if S also conforms to Collection, if
>>> not by adding a specialisation?
>> 
>> The RRC can call into S.someCustomizationPoint(), which will
>> initialize a region of memory in the most efficient way possible,
>> since it has complete knowledge about the memory layout of S.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko > >*/
> 
> Sorry, it’s been a little while since I looked at it 
> (https://github.com/apple/swift/pull/3067 
> ). Actually, the issue is with the 
> append() function specifically - it only has a Sequence specialisation. 
> That’s the point; we were losing type information and not calling the more 
> optimised replaceSubrange — which is exactly the specialisation point you are 
> talking about, Dmitry (I think everything funnels down in to replaceSubrange).
> 
> I must have misunderstood what you were saying at the time. I’ll have to 
> test, but I think it’s still an issue. I thought there was some more general 
> work on RRC planned, so when I saw the bullet I thought maybe that was it.
> 
> @Dave:
> 
> I was trying to initialise a String.CharacterView - depending on whether I 
> initialised it with another CharacterView, or created it empty and appended 
> the other CharacterView, I would get huge performance differences, as the 
> other CharacterView would get split up and a new Character created and 
> appended for every character in the string (which had like 10,000 
> characters). It’s a subtle bug and a bit nasty when it hits you.
> 
> Karl

Ah no, my memory’s coming back - it wasn’t the overhead in the standard library 
that was the biggest problem, as much as the 10,000 calls to replaceSubrange 
with a single element being appended. We had to do some additional processing, 
and it was just killer doing it so many times.

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

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Dmitri Gribenko via swift-evolution]

On Wed, Jul 6, 2016 at 6:15 PM, Karl  wrote:
>
> On 7 Jul 2016, at 02:06, Dmitri Gribenko  wrote:
>
> On Wed, Jul 6, 2016 at 4:21 AM, Karl  wrote:
>
> I had a PR open for this which added a Collection specialisation, but you
> said this could be handled in a more general way which allows for more
> optimised mutations. I’m curious how this would work; how does
> `RangeReplaceableCollection.replaceSubrange(range:, with: S)`
> call a more optimised implementation if S also conforms to Collection, if
> not by adding a specialisation?
>
>
> The RRC can call into S.someCustomizationPoint(), which will
> initialize a region of memory in the most efficient way possible,
> since it has complete knowledge about the memory layout of S.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>
>
> Sorry, it’s been a little while since I looked at it
> (https://github.com/apple/swift/pull/3067). Actually, the issue is with the
> append() function specifically - it only has a Sequence specialisation.
> That’s the point; we were losing type information and not calling the more
> optimised replaceSubrange — which is exactly the specialisation point you
> are talking about, Dmitry (I think everything funnels down in to
> replaceSubrange).

I'm talking about a different customization point.  RRC.append() calls
RRC.replaceSubrange(), which, in our thinking, would call
S._copyContents(initializing: RRC.getInnerPointer()).  _copyContents()
is the customization point on the argument that would initialize
memory with the contents of the sequence.

> I must have misunderstood what you were saying at the time. I’ll have to
> test, but I think it’s still an issue. I thought there was some more general
> work on RRC planned, so when I saw the bullet I thought maybe that was it.

I will be sending a draft proposal soon that will indirectly fix this
performance issue.

Dmitri

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

Re: [swift-evolution] [Draft] Fix the Collection Partition API

[Dave Abrahams via swift-evolution]

on Tue Jul 05 2016, Nate Cook  wrote:

> Hi all,
>
> This is a crack at a proposal to revise the API of the collection
> partition method, called out as an open issue in the standard
> library. What's below is a much shorter revision of a prior proposal,
> focused only on the partition method. I welcome any feedback you might
> have!
>
> Thanks,
> Nate

Overall, a big +1.  Please submit a PR for the proposal to the evolution
repo!

Notes below.

> 
> This proposal revises the signature for the collection partition
> algorithm. Partitioning is a foundational API for sorting and for
> searching through sorted collections.
>
> Swift-evolution thread: Feedback from standard library team
> 
> Swift Bug: SR-1965 
> Motivation
> Based on feedback during the review of proposal SE-0074,
> Implementation of Binary Search Functions
> 
> and the list of open issues affecting standard library API stability
> ,
> this is a revised proposal focused only on the existing collection
> partition method.
>
> The standard library's current partition methods, which partition a
> mutable collection using a binary predicate based on the value of the
> first element of a collection, are used by the standard library's
> sorting algorithm but don't offer more general partitioning
> functionality. A more general partition algorithm using a unary
> (single-argument) predicate would be more flexible and generally
> useful.
>
> Proposed solution
> The standard library should replace the existing partition methods
> with a single method taking a unary predicate. This new method,
> partition(where:), is a mutating method that accepts a unary
> predicate. The elements of the collection are rearranged according to
> the predicate, so that there is a pivot index p where no element
> before p satisfies the predicate and every element at and after p does
> satisfy the predicate.
>
> var n = [30, 40, 20, 30, 30, 60, 10]
> let p = n.partition(where: { $0 > 30 })
> // n == [30, 10, 20, 30, 30, 60, 40]
> // p == 5
> After partitioning, the predicate returns false for every element in
> n.prefix(upTo: p)and true for every element in n.suffix(from: p).
>
> Detailed design
> partition(where:) should be added as a MutableCollection requirement
> with default implementations for mutable and bidirectional mutable
> collections. Any mutable collection can be partitioned, but the
> bidirectional algorithm generally performs far fewer copies. The other
> two methods can be provided in an extension of the Collection
> protocol.
>
> The proposed APIs are collected here:
>
> protocol MutableCollection {
> // existing requirements
>
> /// Reorders the elements of the collection such that all the
> /// elements that match the predicate are ordered after all the
> /// elements that do not match the predicate.
> ///
> /// - Returns: The index of the first element in the reordered
> ///   collection that matches the predicate.
> /// - Complexity: O(n)
> @discardableResult
> mutating func partition(
> where predicate: @noescape (Iterator.Element) throws-> Bool
> ) rethrows -> Index
> }
>
> extension MutableCollection {
> @discardableResult
> mutating func partition(
> where predicate: @noescape (Iterator.Element) throws-> Bool
> ) rethrows -> Index
> }
>
> extension MutableCollection where Self: BidirectionalCollection {
> @discardableResult
> mutating func partition(
> where predicate: @noescape (Iterator.Element) throws-> Bool
> ) rethrows -> Index
> }
> A full implementation of the two default implementations can be found
> in this gist
> .

IMO we should choose a better parameter name for predicate, such as
`belongsInSecondPartition` or `moveToUpperPartition`.  That will help
guide people to correct usage.

> Impact on existing code
> The current sorting algorithms would need to be modified to use the
> new partition(where:) method. 

Not really; that's an implementation detail.  A super cheap fix would
just underscore the existing APIs.  The “Impact on existing code”
section is really about the impact on clients of the standard library,
not its internals.

> Other uses of the existing partition methods could be flagged or in
> theory could be replaced programmatically. The replacement code, on a
> mutable collection c:
>
> // old
> c.partition()
>
> // new
> if let first = c.first {
> c.partition(where: { $0 >= first })
> }
> A thorough, though not exhaustive, search of GitHub for the existing
> partition method found no real evidence of its use. The evident uses
> of a partition method were 

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Karl via swift-evolution]

> On 7 Jul 2016, at 02:06, Dmitri Gribenko  wrote:
> 
> On Wed, Jul 6, 2016 at 4:21 AM, Karl  wrote:
>> I had a PR open for this which added a Collection specialisation, but you
>> said this could be handled in a more general way which allows for more
>> optimised mutations. I’m curious how this would work; how does
>> `RangeReplaceableCollection.replaceSubrange(range:, with: S)`
>> call a more optimised implementation if S also conforms to Collection, if
>> not by adding a specialisation?
> 
> The RRC can call into S.someCustomizationPoint(), which will
> initialize a region of memory in the most efficient way possible,
> since it has complete knowledge about the memory layout of S.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

Sorry, it’s been a little while since I looked at it 
(https://github.com/apple/swift/pull/3067 
). Actually, the issue is with the 
append() function specifically - it only has a Sequence specialisation. That’s 
the point; we were losing type information and not calling the more optimised 
replaceSubrange — which is exactly the specialisation point you are talking 
about, Dmitry (I think everything funnels down in to replaceSubrange).

I must have misunderstood what you were saying at the time. I’ll have to test, 
but I think it’s still an issue. I thought there was some more general work on 
RRC planned, so when I saw the bullet I thought maybe that was it.

@Dave:

I was trying to initialise a String.CharacterView - depending on whether I 
initialised it with another CharacterView, or created it empty and appended the 
other CharacterView, I would get huge performance differences, as the other 
CharacterView would get split up and a new Character created and appended for 
every character in the string (which had like 10,000 characters). It’s a subtle 
bug and a bit nasty when it hits you.

Karl


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

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 6, 2016, at 6:50 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Wed Jul 06 2016, Dave Abrahams  wrote:
>> 
>> Finally, as mentioned earlier we could easily supply a protocol that
>> makes it no harder than conforming to IteratorProtocol is.  You don't
>> even need to make your iteration state equatable because we can compare
>> counters stored in the indices.  I'll post a gist illustrating this
>> today.
> 
> https://gist.github.com/dabrahams/7629347b76c8d87ce8278e68ae70469f

Thanks for sharing!  It's great to have a clear and concise example showing how 
easy it can be to support Collection.  

We should keep the the Comparable requirement and probably drop Sequence.

I plan to comment on finite vs infinite but want to see the rest of the plans 
the library team is working before I do so.

Matthew

> 
> Enjoy,
> 
> -- 
> 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] Dropping Comparable requirement for indices

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 6, 2016, at 7:33 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I for one would be interested in your elaboration. Based on Dave's comments, 
> I'm pretty convinced that the Comparable requirement is best left in place.

+1

>> On Wed, Jul 6, 2016 at 19:19 plx via swift-evolution 
>>  wrote:
>> My own 2c is to drop the comparable requirement.
>> 
>> I can elaborate if necessary, but wanted to at least cast my “+1” for 
>> removing the requirement.
>> 
>> > On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution 
>> >  wrote:
>> >
>> >
>> > I've already raised the question here of whether we should weaken the
>> > requirement that Collection.Index be Comparable to merely being
>> > Equatable.
>> >
>> > Part of the motivation was to support data structures that otherwise
>> > would be expensive or impossible to implement.  For example, with
>> > Comparable indices, you can't build a linked list that supports
>> > restructuring (e.g. insert, delete, splice) in O(1) without invalidating
>> > indices... not even an unsafe linked list with reference semantics.
>> > [While I don't think linked lists are terribly good data structures for
>> > most things, they are still useful in teaching, and it bothered me that
>> > we were ruling them out.]  Even if you take away the index invalidation
>> > restriction, you have to store a counter in the index, which is an awkward 
>> > inefficiency.
>> > Supporting Comparable indices for a tree data structure requires
>> > encoding the path from the root to the node.  It's only one or two words
>> > in practice, but it's another awkward inefficiency.
>> >
>> > Over the weekend, I tried lifting the restriction to see what kind of
>> > effect it would have on the standard library.
>> > https://github.com/apple/swift/pull/3325
>> >
>> > Although I *had* been leaning strongly toward making this change, having
>> > looked at the effects, I am now more ambivalent:
>> >
>> > * A Range, where T is not Comparable, could be constructed with any
>> >  pair of Equatable T instances.  We'd only detect that the Range may be
>> >  invalid when T happened to also be Comparable.  However, the fact that
>> >  you are creating a Range already sort of implies an underlying
>> >  ordering.
>> >
>> > * A Collection with non-Comparable indices still imposes an ordering
>> >  upon the indices.
>> >
>> > * In a Collection with Comparable indices, the ordering implied by <
>> >  needs to match the ordering of indices in the collection.  Otherwise,
>> >  there would be no way to form Ranges (for use in slicing, for example)
>> >  without causing a trap.  This is *weird*!  There's little precedent
>> >  for imposing stronger semantic requirements on an associated type if
>> >  it conforms to a particular protocol (Comparable in this case), except
>> >  where the requirement is part of the protocol.
>> >
>> > Also, Dmitri reminded me that even with a Comparable requirement on
>> > indices, there is still no problem converting an equatable iteration
>> > state into an index; you just need to augment it with an integer
>> > counter.  So it's still trivial to create a Collection from nearly
>> > everything that is today a multipass Sequence.  It does make indexing
>> > slightly more expensive, but it's likely we'd optimize that overhead
>> > away in many critical situations.
>> >
>> > Anyway, the thoughts of the community on this topic would be interesting
>> > to us.  We need to make a decision about this very soon.
>> >
>> > Thanks!
>> >
>> > --
>> > 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 mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 6, 2016, at 6:47 PM, Scott James Remnant  wrote:
> 
> 
>>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson  wrote:
>>> 
>>> To give you an example of the confusion, here is code made perfectly legal 
>>> by SE-0025:
>>> 
>>>   public final class Example {
>>> 
>>> overridable func foo() {}
>>> 
>>>   }
>> 
>> I have no idea how you think this is related to SE-0025 (scoped access 
>> control).  I also don’t understand why you think an `overridable` method in 
>> a `final` class would be legal under any proposal.  That is nonsense and 
>> clearly in error.
> 
> SE-0117, which we are reviewing here, in its introduction introduces the new 
> `subclassable` and `overridable` modifiers in a discussion about `public`, 
> and indicates that they are used instead of that keyword. This to me strongly 
> implies that these are in the same family as the access control modifiers.
> 
> SE-0025 removes the error when the access of a member within a type is less 
> restrictive, thus removes the error that would otherwise occur with the above 
> code.

SE-0025 says nothing about final though.  I really don't think we would allow 
overridable in a final class in any case.

I do think it's fair to point out that details like is are not fully specified 
in the proposal and  should be (in order to avoid another round of cleanup 
similar to what was necessary for SE-0025).

> 
> 
> Consider this another strong argument for keeping access and inheritability 
> separate, the following code would be obviously an error/warning since `open` 
> makes no sense within a `final` class:
> 
>   public final class Example {
> 
> public open func foo() {}
> 
>   }
> 
> Clarity is always a goal for Swift. This to me has more of it than replacing 
> `public`.
> 
> Scott
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Dropping Comparable requirement for indices

[Xiaodi Wu via swift-evolution]

I for one would be interested in your elaboration. Based on Dave's
comments, I'm pretty convinced that the Comparable requirement is best left
in place.
On Wed, Jul 6, 2016 at 19:19 plx via swift-evolution <
swift-evolution@swift.org> wrote:

> My own 2c is to drop the comparable requirement.
>
> I can elaborate if necessary, but wanted to at least cast my “+1” for
> removing the requirement.
>
> > On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > I've already raised the question here of whether we should weaken the
> > requirement that Collection.Index be Comparable to merely being
> > Equatable.
> >
> > Part of the motivation was to support data structures that otherwise
> > would be expensive or impossible to implement.  For example, with
> > Comparable indices, you can't build a linked list that supports
> > restructuring (e.g. insert, delete, splice) in O(1) without invalidating
> > indices... not even an unsafe linked list with reference semantics.
> > [While I don't think linked lists are terribly good data structures for
> > most things, they are still useful in teaching, and it bothered me that
> > we were ruling them out.]  Even if you take away the index invalidation
> > restriction, you have to store a counter in the index, which is an
> awkward inefficiency.
> > Supporting Comparable indices for a tree data structure requires
> > encoding the path from the root to the node.  It's only one or two words
> > in practice, but it's another awkward inefficiency.
> >
> > Over the weekend, I tried lifting the restriction to see what kind of
> > effect it would have on the standard library.
> > https://github.com/apple/swift/pull/3325
> >
> > Although I *had* been leaning strongly toward making this change, having
> > looked at the effects, I am now more ambivalent:
> >
> > * A Range, where T is not Comparable, could be constructed with any
> >  pair of Equatable T instances.  We'd only detect that the Range may be
> >  invalid when T happened to also be Comparable.  However, the fact that
> >  you are creating a Range already sort of implies an underlying
> >  ordering.
> >
> > * A Collection with non-Comparable indices still imposes an ordering
> >  upon the indices.
> >
> > * In a Collection with Comparable indices, the ordering implied by <
> >  needs to match the ordering of indices in the collection.  Otherwise,
> >  there would be no way to form Ranges (for use in slicing, for example)
> >  without causing a trap.  This is *weird*!  There's little precedent
> >  for imposing stronger semantic requirements on an associated type if
> >  it conforms to a particular protocol (Comparable in this case), except
> >  where the requirement is part of the protocol.
> >
> > Also, Dmitri reminded me that even with a Comparable requirement on
> > indices, there is still no problem converting an equatable iteration
> > state into an index; you just need to augment it with an integer
> > counter.  So it's still trivial to create a Collection from nearly
> > everything that is today a multipass Sequence.  It does make indexing
> > slightly more expensive, but it's likely we'd optimize that overhead
> > away in many critical situations.
> >
> > Anyway, the thoughts of the community on this topic would be interesting
> > to us.  We need to make a decision about this very soon.
> >
> > Thanks!
> >
> > --
> > 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 6, 2016, at 6:39 PM, Scott James Remnant  wrote:
> 
> 
>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson  wrote:
>> 
>> Many of us believe “final” is too blunt a tool.  There are many cases where 
>> final cannot be used but you still don’t want external users subclassing or 
>> overriding.  
>> 
>> We would like a more precise tool for these circumstances and believe if it 
>> is going to exist in Swift it should be the default.  Its behavior follows 
>> the principle of requiring programmers to explicitly make decisions about 
>> what behavior is exposed outside of a module.  You may not like that 
>> principle, but it is one that has been embraced by the language.
> 
> I am all for these things, and would be in favor of a proposal that does this 
> cleanly(*)… the proposal text I reviewed does not.
> 
> * e.g. the final/sealed/open keywords you suggest, with sealed being the new 
> default, makes a huge amount of sense to me and feels clean, since it keeps 
> access and finality separate, and as you say, explicitly make decisions in a 
> manner otherwise consistent with the language.

Great!  I agree with you that the specific details of the proposal can be 
improved.  The core team is free to "accept with revision" and that's what I 
hope they do in this case.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jonathan Hull via swift-evolution]

> * What is your evaluation of the proposal?
A **strong** -1

First, I have often found that you can’t always predict the way which something 
will need to be extended.  You think you know, but are then surprised by 
creative uses.  My favorite features of Swift/Cocoa involve retroactive 
modeling.

Second, I don’t think this proposal will achieve its stated objective of 
forcing people to think about subclassing more.  It will just add confusing 
boilerplate.  

Things like Swift optionals work well because they make the (often forgotten) 
choices explicit in the context that they are used.  In the world of Human 
Factors, we call it a forcing function.  This proposal has the inverse 
structure, and will be ineffective, because the “forcing” part of it shows up 
in a different context (i.e. trying to use a framework) than the decision is 
being made in (writing the framework).  This type of thinking leads to things 
like Java and the DMV.

As Tino said:
> No matter what the defaults are, good libraries are hard to build, so I 
> predict this proposal would not only fail in increasing framework quality, 
> but also will make it much harder for users of those frameworks to work 
> around their flaws, which are just a natural part of every software.

I think he is right on here.  Those who were prone to be thoughtful about their 
design would have been anyway.  Those who are not thoughtful about their design 
will just leave these annotations off… leaving us with no recourse to 
extend/modify classes.  When people complain, they will add the annotations 
without actually thinking about the meaning (i.e. stack overflow / the fixit 
tells me I need to add this word to make the compiler happy).  All this does is 
put framework users at the mercy of the framework writers.


Finally, this proposal is missing important aspects of the problem space.  If 
we truly want to solve the issue of subclassing, we need to consider all of the 
common issues which arise.  Looking at the cocoa documentation you will see 
several types of annotations:
1) This method MUST be overridden
2) This method should NOT be overridden
3) This method MUST be called
3) This method should NOT be called except by subclasses
4) This method should NOT be called except by a method override calling 
super
5) This method MUST call super
6) Overrides of this method should NOT call super

If we are attempting to bring thoughtfulness to the design of classes, I would 
like to see things be extendable by default, but with annotations that 
thoughtful framework designers can use to designate how a particular method 
should be used.  In most cases, it should not explicitly forbid the end user 
from subclassing, but require them to acknowledge that what they are doing is 
not intended by the framework. (e.g. "unsafe override func"…).  That would feel 
1000x more swifty to me.  Opt-out safety.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
No. It doesn’t actually solve the problem... and I haven’t actually run into 
this problem in the real world.
> * Does this proposal fit well with the feel and direction of Swift?
No, it gives Swift more of a feeling of busywork and unnecessary boilerplate 
while failing to achieve its objective.  It goes against the retroactive 
modeling allowed by other areas of Swift.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
I tend to avoid languages which require this sort of thing.  In other languages 
that lock things down, there is a need to unlock things soon after (e.g. friend 
classes).  

I predict the same thing will happen here.  People will quickly be asking for 
the ability to patch/override in cases where the framework designer was wrong.  
That shows a problem inherent with the design...

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read the proposal & discussion.  Read earlier discussions around access control 
that touched on this subject as well.  I have been designing frameworks for 
years.

Thanks,
Jon

> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes 

Re: [swift-evolution] Dropping Comparable requirement for indices

[plx via swift-evolution]

My own 2c is to drop the comparable requirement.

I can elaborate if necessary, but wanted to at least cast my “+1” for removing 
the requirement.

> On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> I've already raised the question here of whether we should weaken the
> requirement that Collection.Index be Comparable to merely being
> Equatable.  
> 
> Part of the motivation was to support data structures that otherwise
> would be expensive or impossible to implement.  For example, with
> Comparable indices, you can't build a linked list that supports
> restructuring (e.g. insert, delete, splice) in O(1) without invalidating
> indices... not even an unsafe linked list with reference semantics.
> [While I don't think linked lists are terribly good data structures for
> most things, they are still useful in teaching, and it bothered me that
> we were ruling them out.]  Even if you take away the index invalidation
> restriction, you have to store a counter in the index, which is an awkward 
> inefficiency.
> Supporting Comparable indices for a tree data structure requires
> encoding the path from the root to the node.  It's only one or two words
> in practice, but it's another awkward inefficiency.
> 
> Over the weekend, I tried lifting the restriction to see what kind of
> effect it would have on the standard library.
> https://github.com/apple/swift/pull/3325
> 
> Although I *had* been leaning strongly toward making this change, having
> looked at the effects, I am now more ambivalent:
> 
> * A Range, where T is not Comparable, could be constructed with any
>  pair of Equatable T instances.  We'd only detect that the Range may be
>  invalid when T happened to also be Comparable.  However, the fact that
>  you are creating a Range already sort of implies an underlying
>  ordering.
> 
> * A Collection with non-Comparable indices still imposes an ordering
>  upon the indices.
> 
> * In a Collection with Comparable indices, the ordering implied by <
>  needs to match the ordering of indices in the collection.  Otherwise,
>  there would be no way to form Ranges (for use in slicing, for example)
>  without causing a trap.  This is *weird*!  There's little precedent
>  for imposing stronger semantic requirements on an associated type if
>  it conforms to a particular protocol (Comparable in this case), except
>  where the requirement is part of the protocol.
> 
> Also, Dmitri reminded me that even with a Comparable requirement on
> indices, there is still no problem converting an equatable iteration
> state into an index; you just need to augment it with an integer
> counter.  So it's still trivial to create a Collection from nearly
> everything that is today a multipass Sequence.  It does make indexing
> slightly more expensive, but it's likely we'd optimize that overhead
> away in many critical situations.
> 
> Anyway, the thoughts of the community on this topic would be interesting
> to us.  We need to make a decision about this very soon.
> 
> Thanks!
> 
> -- 
> 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] Open Issues Affecting Standard Library API Stability

[Dmitri Gribenko via swift-evolution]

On Wed, Jul 6, 2016 at 4:21 AM, Karl  wrote:
> I had a PR open for this which added a Collection specialisation, but you
> said this could be handled in a more general way which allows for more
> optimised mutations. I’m curious how this would work; how does
> `RangeReplaceableCollection.replaceSubrange(range:, with: S)`
> call a more optimised implementation if S also conforms to Collection, if
> not by adding a specialisation?

The RRC can call into S.someCustomizationPoint(), which will
initialize a region of memory in the most efficient way possible,
since it has complete knowledge about the memory layout of S.

Dmitri

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

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Jacob Bandes-Storch  wrote:

> On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > Remove unsafeAddressOf. We are not aware of any real usecases for it. If
>> there are any, it should be renamed to unsafeAddress(of:) to follow the
>> guidelines.
>> Obvious, unless someone comes up with use cases during the review period.
>>
>>
> It's minor, but I use unsafeAddressOf regularly for writing `description`
> methods:
>
> var description: String {
> return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info
> here... }"
> }

You can do that, but there's no guarantee that the address is
meaningful.  The compiler is free to copy self into a writeback buffer
whose address gets printed.

> I guess this would be covered by some generalized solution for format
> specifiers in string interpolations, but I gather that won't happen for
> quite a while...

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

[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jakub Suder via swift-evolution]

> What is your evaluation of the proposal?

Strong -1 from me.

I agree that subclassing library classes that were not explicitly planned
to be subclassed might sometimes lead to bugs. But just because a technique
or feature of a language allows you to sometimes make mistakes, it doesn't
mean it should be completely disallowed. By this logic, we'd have to remove
all instances of "!" any anything related to pointers from Swift. It's
possible for a feature to allow you to shoot yourself in the foot, and
still be useful at the same time.

We've removed things like C-style for loops or "if object {" shorthand from
Swift, because we have cleaner ways of achieving the same goals in a
different way, so it was safe to remove them without making the language
less powerful. But here we would be removing a feature for which there is
no workaround. If I need to override some methods from a binary library or
SDK that I use in my app (e.g. Crashlytics, Zendesk - yes, these are ObjC
libraries, but I'm speaking about the future), in order to work around some
bugs, customize or adapt the behavior to my app (e.g. UI styling,
copywriting, i18n), then there's no other way to do achieve this, other
than rewriting the whole thing from scratch. Even if I do have access to
the source code, keeping your extensions in a subclass in your app is a
much cleaner solution that hacking the library code directly (and getting
merge conflicts later). One day, Apple system frameworks will also be
written in Swift, and this change will make it harder to use them.

Of course, the above is only a problem if the class hasn't been marked as
subclassable. But I'm afraid that in most cases it won't be, even if it
could be, simply because:

1) the author hasn't foreseen I'd need this (how could they foresee every
possible use case and requirement? if they had known what I'm going to
need, I wouldn't need to write a subclass in the first place)

2) or, more likely, they just didn't remember about this feature or didn't
realize at all that they need to add this subclassable keyword to make this
possible. Or they did, but they forgot to add it to some new code.

The proposed 'subclassable' and 'overridable' keywords would also introduce
a lot of noise to the library code, if the author wanted to make most or
all of their code extensible. A single 'open' keyword would be preferred,
and adding it only to the class and not the methods (marking class as open
makes whole class and its methods non-final) would be even better, since it
would make it more likely library authors would actually use it (though
still only a "lesser evil").

As for the performance aspect - I don't think a minor speedup should be a
reason to remove a useful feature from the language, it would be most
likely a case of premature optimization. If necessary, you can always mark
a critical class as final if profiling shows that it's being called all the
time, and leave all the other classes open by default.


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

I don't think the problem is significant, and I'm afraid the proposed
solution is worse than the problem itself.

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

I don't feel qualified to answer this.

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

I've used Ruby and JavaScript for many years each, and ObjC for a few
years. In my opinion, all three give the developer much more power when it
comes to using code in creative and unplanned ways when that's what you
need to achieve your goals, than Swift does currently. That's especially
the case with the first two - ObjC already felt too restrictive in many
ways for me.

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

I've read the proposal and skimmed through the responses thread.

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

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Karl  wrote:

> I’m quite interested in this point:
>
>> Figure out whether RangeReplaceableCollection.replaceRange should accept a 
>> Sequence as its argument, and if so implement it.
>
> At the moment `replaceSubrange` takes a sequence, 

No, actually at the moment it takes a Collection.

> and lots of methods on RangeReplaceableCollection use that to perform
> their mutation operations. That means that Collections gets iterated
> item-by-item; for example, a String will get parsed out in to
> Characters and added individually to the existing string. 

And a String is neither a Sequence nor a Collection.

> In general, depending on which methods you use to mutate a RRC, you
> can expect wildly different performance characteristics. So it’s more
> important to fix than the name might suggest.

It depends on the RRC.  Some RRCs can be restructured at the front or
back more cheaply than in the middle.

> I had a PR open for this which added a Collection specialisation, but
> you said this could be handled in a more general way which allows for
> more optimised mutations. I’m curious how this would work; how does
> `RangeReplaceableCollection.replaceSubrange(range:, with:
> S)` call a more optimised implementation if S also conforms to
> Collection, if not by adding a specialisation?

I'm sorry, I don't know what you're referring to here.  If you have
specific questions about a response to a PR, could you ask them in the
PR?  (It doesn't have to be open)

>> On 6 Jul 2016, at 07:50, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> 
>> On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner  wrote:
>>> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution 
>>>  wrote:
 
 Hi swift-evolution,
 
 Dave, Max and I have compiled a list of open issues in the standard
 library for which the resolutions could result non-additive API
 changes.  Having a resolution (and an implementation of the
 resolution!) for these issues is blocking API stability.
 
 https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d
>>> 
>>> Thank you for collecting this Dmitri!  For the issues in the “low
>>> hanging fruit” list, are the changes all sufficiently "obvious”?
>>> If so, having one proposal tackle all of them in one sweep would be
>>> preferable to reduce process overhead.
>> 
>> My subjective assessment:
>> 
>>> The global function withUnsafe[Mutable]Pointer() should have an argument 
>>> label “to”.
>> Obvious.
>> 
>>> UnicodeScalar.init(Int) should be failable.
>> Obvious.
>> 
>>> withUnsafePointer shouldn't take its argument as inout.
>> Jordan has objections, see https://bugs.swift.org/browse/SR-1956
>> 
>>> Remove unsafeAddressOf. We are not aware of any real usecases for
>>> it. If there are any, it should be renamed to unsafeAddress(of:) to
>>> follow the guidelines.
>> Obvious, unless someone comes up with use cases during the review period.
>> 
>>> Consider renaming or eliminating ManagedProtoBuffer.
>>> The reason why ManagedProtoBuffer exists is to give the users an
>>> extra bit of type safety inside of the closure passed to
>>> ManagedBuffer.create().
>> Debatable.
>> 
>>> String.CharacterView.Iterator should be a custom type rather than
>>> the default, to allow performance optimizations. Audit all other
>>> collections for such opportunities.
>> Obvious.
>> 
>>> String(count:, repeatedValue:) and String.append() are ambiguous without an 
>>> explicit cast to Character.
>> Obvious.
>> 
>>> Rename the ~LiteralConvertible protocols according to the resolution of the 
>>> proposal currently under review.
>> A separate review.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

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

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Dave Abrahams  wrote:

> Finally, as mentioned earlier we could easily supply a protocol that
> makes it no harder than conforming to IteratorProtocol is.  You don't
> even need to make your iteration state equatable because we can compare
> counters stored in the indices.  I'll post a gist illustrating this
> today.

https://gist.github.com/dabrahams/7629347b76c8d87ce8278e68ae70469f

Enjoy,

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson  wrote:
>> 
>> To give you an example of the confusion, here is code made perfectly legal 
>> by SE-0025:
>> 
>>   public final class Example {
>> 
>> overridable func foo() {}
>> 
>>   }
> 
> I have no idea how you think this is related to SE-0025 (scoped access 
> control).  I also don’t understand why you think an `overridable` method in a 
> `final` class would be legal under any proposal.  That is nonsense and 
> clearly in error.
> 

SE-0117, which we are reviewing here, in its introduction introduces the new 
`subclassable` and `overridable` modifiers in a discussion about `public`, and 
indicates that they are used instead of that keyword. This to me strongly 
implies that these are in the same family as the access control modifiers.

SE-0025 removes the error when the access of a member within a type is less 
restrictive, thus removes the error that would otherwise occur with the above 
code.


Consider this another strong argument for keeping access and inheritability 
separate, the following code would be obviously an error/warning since `open` 
makes no sense within a `final` class:

  public final class Example {

public open func foo() {}

  }

Clarity is always a goal for Swift. This to me has more of it than replacing 
`public`.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson  wrote:
> 
> Many of us believe “final” is too blunt a tool.  There are many cases where 
> final cannot be used but you still don’t want external users subclassing or 
> overriding.  
> 
> We would like a more precise tool for these circumstances and believe if it 
> is going to exist in Swift it should be the default.  Its behavior follows 
> the principle of requiring programmers to explicitly make decisions about 
> what behavior is exposed outside of a module.  You may not like that 
> principle, but it is one that has been embraced by the language.
> 

I am all for these things, and would be in favor of a proposal that does this 
cleanly(*)… the proposal text I reviewed does not.

* e.g. the final/sealed/open keywords you suggest, with sealed being the new 
default, makes a huge amount of sense to me and feels clean, since it keeps 
access and finality separate, and as you say, explicitly make decisions in a 
manner otherwise consistent with the language.

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[David Waite via swift-evolution]

I see two possible approaches:

1. A “import Libc” imports the platform libraries, whatever they may be, on the 
OS platform you are on.

2. The OS platform libraries are divided up, virtually if necessary, to expose 
the underlying standard interfaces without platform-specific extensions. I 
imagine that would look similar to 
https://gist.github.com/dwaite/c7125680def834e93ba1fae8873ce1f8:

┌─┐  
   ┌│ Foundation  ├┐ 
   │  Platform-specific └┬┘├┐
   │  ┌──┐   └┬┬───┘│
   │  │Linux │└┼┘
   │  │  ┌┐  │ │ 
   ├──┼──│ GLibc  │  │ │ 
   │  │  └┘  │ │ 
   │  │  │ │ 
 C Standard│  ├──┤ │ 
   Library ▼  │  Apple OSes  │ │ 
┌┐   ┌┐   ┌┐  │  ┌┐  │ │ 
│ Swift  │◀──│  Libc  │◀──│ Posix  │◀─┼──│ Darwin │◀─┼─┤ 
└┘   └┘   └┘  │  └┘  │ │ 
  ▲   │  │ │ 
  │   ├──┤ │ 
  │   │   Windows│ │ 
  │   │  ┌┐  │ │ 
  └───┼──│ Win32  │◀─┼─┘ 
  │  └┘  │   
  │  │   
  └──┘   


My feeling is that while dealing with imported code, it is understandable you 
will have API that differs per platform. Once you start adding object or 
protocol-oriented design on top, it is expected that the additional layer will 
abstract those differences away.

-DW

> On Jul 5, 2016, at 6:28 PM, Saleem Abdulrasool via swift-evolution 
>  wrote:
> 
> On Tuesday, July 5, 2016, Chris Lattner  wrote:
> 
>> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution 
>>  wrote:
>> 
>> Sorry to resurrect such an old thread! I understand getting this in Swift 
>> 3.0 might not be realistic anymore, but this is still something I’d love to 
>> see added to Swift. Could someone advise on whether it still makes sense to 
>> spend time on this proposal? Or is this part of Swift too solidified to 
>> change at this point?
>> 
> It is definitely beyond Swift 3.0, but I’d love to see this happen at some 
> point, we really need someone to drive the (surely to be contentious) design 
> process.
> 
> I'm probably going to regret this, but given that I had originally proposed 
> this to Brian and would really like to see this happen, what does this entail?
>  
> -Chris
> 
> 
>> How much would Libc include? The standard C library? POSIX?
>> 
>> Yes, I had originally anticipated this as including module C and module 
>> POSIX. I see that module CUUID was recently added as well, but I don’t think 
>> that should be included.
>> 
>> there are differences (minor, but still) between Glibc and Darwin. Those 
>> should be either unified (if possible) or re-arranged so that the unified 
>> library shares unified functionality and then each separate one can have its 
>> own set of caveats.
>> 
>> I don’t think the unified import C module should do anything besides obviate 
>> the need to write the following:
>> 
>> #if os(Linux) || os(FreeBSD
>> )
>> 
>> import Glibc
>> 
>> #
>> else
>> 
>> 
>> import Darwin
>> 
>> #endif
>> 
> This is about to me made worse with me trying to get Windows support.  How 
> does this look?
> 
>  #if os(Linux) || os(FreeBSD) || os(PS4)
>import Glibc
>  #elseif os(macOS) || os(iOS) || os(tvOS) || os(watchOS)
>   import Darwin
>  #elseif os(Windows) && (_environment(msvc) || _environment(gnu))
>   import msvc
>  #else
>   import glibc
>  #endif
>> 
>> If people feel strongly about unifying the overlay, perhaps we should 
>> discuss that in future swift-evolution proposals.
>> 
> I would be interested in that as well. 
>> Personally, I like “import C”, but at the end of the day I’m happy to call 
>> it whatever as long as it solves the problem.
>> 
>> I couldn’t have said it better myself!
>> 
>> /cc Saleem, since he may have Windows opinions.
>> 
>> - Brian Gesiak
>> 
>> 
>> On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky  wrote:
>> A huge +1 on the proposal, I even have a code snippet to 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

> On Jul 6, 2016, at 5:13 PM, Scott James Remnant  wrote:
> 
> 
>> On Jul 6, 2016, at 2:47 PM, Matthew Johnson > > wrote:
>> 
>> This is not true.  Public classes will *not* be “final by default”.  It 
>> *will* be possible to subclass them within their declaring module.  If they 
>> need to be final they will still need to be marked as such.  
>> 
>> With that in mind, the your “can override” column (do you really mean “can 
>> subclass” here?) is also not correct.  The correct answer is “yes, within 
>> the module”.  The fundamental difference for this row is that there are some 
>> scopes which can *see* the type without the ability to subclass it.  There 
>> is no problem with this, it is *exactly* what we want.  
> 
> So would this be more accurate?
> 
>   access  | can access| can subclass/  | final
>   |   | override where |
>  -+---++---
>   open| all scopes| all scopes | Error
>   public  | all scopes| within module  | final
>   internal| within module | within module  | final
>   fileprivate | within file   | within file| final
>   private | within scope  | within scope   | final

If you want to view “open” as an access modifier, then yes.

> 
>> The purpose of this proposal is precisely to give library authors the 
>> ability to have more fine grained control over what capabilities their 
>> library exposes to users.
>> 
> 
> I don’t have an issue with the purpose, I have an issue with doing it by 
> conflating access control and finality, and making the language confusing as 
> a result.

It’s not conflating access control and finality.

It is also possible to view “open” and “sealed" as part of an “inheritability" 
hierarchy rather than the access control hierarchy. 

final- never subclassable / overridable
sealed (default)  - subclassable / overridable *within* the declaring module
open   - always subclassable / overridable

In some sense, “open” intersects access control and inheritability:  it only 
makes sense on a public declarations and therefore implies public (whether we 
allow public to be inferred or not).

> 
> Assuming the above table matches your expectation, compare it with the same 
> matrix for the language as it is today:
> 
>   access  | can access| can subclass/  | final
>   |   | override where |
>  -+---++---
>   public  | all scopes| all scopes | final
>   internal| within module | within module  | final
>   fileprivate | within file   | within file| final
>   private | within scope  | within scope   | final
> 
> The existing table is clean, it’s easy to understand; the two concepts are 
> entirely separate from each other. The access control keyword defines where a 
> class, method, property, or subscript can be accessed from; the `final` 
> keyword defines whether or not it can be subclassed or overridden.

Many of us believe “final” is too blunt a tool.  There are many cases where 
final cannot be used but you still don’t want external users subclassing or 
overriding.  

We would like a more precise tool for these circumstances and believe if it is 
going to exist in Swift it should be the default.  Its behavior follows the 
principle of requiring programmers to explicitly make decisions about what 
behavior is exposed outside of a module.  You may not like that principle, but 
it is one that has been embraced by the language.

> 
> 
> To give you an example of the confusion, here is code made perfectly legal by 
> SE-0025:
> 
>   public final class Example {
> 
> overridable func foo() {}
> 
>   }

I have no idea how you think this is related to SE-0025 (scoped access 
control).  I also don’t understand why you think an `overridable` method in a 
`final` class would be legal under any proposal.  That is nonsense and clearly 
in error.

-Matthew

> 
> Scott

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

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

[Ben Rimmington via swift-evolution]

> On 6 Jul 2016, at 18:09, Douglas Gregor  wrote:
> 
>> On Jul 5, 2016, at 10:35 PM, Ben Rimmington > > wrote:
>> 
>>> On 5 Jul 2016, at 21:41, Douglas Gregor >> > wrote:
>>> 
 The following comment is incorrect, AFAIK. The `helpAnchor` is the name 
 attribute of a HTML anchor element.
 
/// A localized message providing "help" text if the user requests help.
var helpAnchor: String? { get }
>>> 
>>> Apple’s documentation says:
>>> 
>>> NSHelpAnchorErrorKey
>>> The corresponding value is an NSString containing the localized help 
>>> corresponding to the help button. See helpAnchor 
>>> 
>>>  for more information.
>>> 
>> 
>> A `helpAnchor` in AppKit is the name of an HTML anchor element:
>> 
>> AppKit > NSPrintPanel > helpAnchor
>> >  
>> >
>> 
>> AppKit > NSHelpManager > openHelpAnchor(_:inBook:)
>> >  
>> >
>> 
>> Apple Help Programming Guide > Authoring Apple Help > Indexing Your Help 
>> Book > Setting Anchors
>> >  
>> >
> 
> The relevant “helpAnchor” is from the NSError reference documentation:
> 
>   
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSError_Class/#//apple_ref/occ/instp/NSError/helpAnchor
>  
> 
> 
> which says:
> 
> A string to display in response to an alert panel help anchor button being 
> pressed. (read-only)
> 
> Declaration
> SWIFT
> var helpAnchor: String 
> ?
>  { get }
> OBJECTIVE-C
> @property(readonly, copy) NSString  
> *helpAnchor
> Discussion
> The object in the user info dictionary for the key NSHelpAnchorErrorKey 
> .
>  If the user info dictionary doesn’t contain a value for NSHelpAnchorErrorKey 
> ,
>  this property is nil.
> 
> If this property is non-nil for an error being presented by alertWithError: 
> ,
>  the alert panel will include a help anchor button that can display this 
> string.
> 
> Availability
> Available in OS X v10.6 and later.
> 
>   - Doug
> 

The documentation on NSError help anchors is incorrect.



I've tested this with a document-based Cocoa application. In the NSDocument 
subclass, I modified the template as follows:

override func data(ofType typeName: String) throws -> Data {
throw NSError(domain: NSOSStatusErrorDomain, code: unimpErr, 
userInfo: [NSHelpAnchorErrorKey: "ibks5f526382"])
}

override func read(from data: Data, ofType typeName: String) throws {
throw NSError(domain: NSOSStatusErrorDomain, code: unimpErr, 
userInfo: [NSHelpAnchorErrorKey: "pbhlp3714a9d"])
}

Those help anchors were copied from the following file (in macOS 10.11.5):


When I try to open or save a document, an NSAlert with a help button is 
presented. Clicking on that help button shows the expected help page:

{"name":"Read books in iBooks","href":"help:anchor='ibks5f526382' 
bookID='com.apple.iBooksX.help'"}

{"name":"Take a Photo Booth photo","href":"help:anchor='pbhlp3714a9d' 
bookID='com.apple.PhotoBooth.help'"}

But if I use a normal word or phrase with NSHelpAnchorErrorKey, the Mac Help 
window displays:

The selected topic is currently unavailable.
The topic you were 

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

[Xiaodi Wu via swift-evolution]

Another use case: I've got a BitArray that makes sense to conform to
BitwiseOperations, but it definitely isn't a FixedWidthInteger.


On Wed, Jul 6, 2016 at 17:56 Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> OptionSets do conform to AlgebraSet but they require raw value type to
> conform to BitwiseOperations.
>
> Max
>
> > On Jul 6, 2016, at 3:44 PM, Jordan Rose  wrote:
> >
> > Option sets use set notation, not bitwise notation, no?
> >
> > Jordan
> >
> >> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> FixedWidthInteger only handles the implementation for the numbers, we
> should also consider OptionSet.
> >>
> >> I think we should keep the protocol in case someone wants to implement
> their own type other than an integer to be used as a raw value type in the
> OptionSet.
> >>
> >> As for renaming it, how about BitwiseOperand?
> >>
> >> protocol BitwiseOperand {
> >> func bitwiseOr(_ rhs: Self) -> Self
> >> func bitwiseAnd(_ rhs: Self) -> Self
> >> // etc ...
> >> }
> >>
> >> Max
> >>
> >>> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>>
> >>> on Fri Jul 01 2016, Riley Testut  wrote:
> >>>
>  Hi all,
> 
>  This is probably very minor, but I’m not sure the protocol name
>  “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>  the guidelines have to say about protocol names:
> 
>  Protocols that describe what something is should read as nouns (e.g.
> Collection).
> 
>  Protocols that describe a capability should be named using the
>  suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
> 
>  From these two, BitwiseOperations appears to be (attempting) to follow
>  the first rule, yet “BitwiseOperations” doesn’t really describe what
>  the type is, but rather that it can do bitwise operations. The
>  documentation itself even describes the protocol as “a type that
>  supports standard bitwise arithmetic operators."
> 
>  I propose we rename it to “BitwiseOperable”, or something
>  similar. Again, a small change, but if this were to ever happen, I
>  think Swift 3 is the time.
> >>>
> >>> BitwiseOperations should really be retired after
> >>>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
> >>> is implemented, and its uses replaced by FixedWidthInteger.
> >>>
> >>> --
> >>> 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 mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ricardo Parada via swift-evolution]

> On Jul 5, 2016, at 7:11 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
>* What is your evaluation of the proposal?

-1

Perhaps because this is so different from what I have seen in other languages 
and used for so many years. I have not worked with a language that uses 
non-subclassable/ non-overridable as the default. 

I think that by default classes should be subclassable, not the other way 
around. I am afraid that developers will not take the time to specify which 
methods are overridable resulting in libraries that are difficult to patch, 
extend. 

In my 26+ years of object-oriented design and programming (other languages, 
Objective-C since 1990 and Java since 2001) I have worked with object oriented 
libraries and subclassed methods that the authors probably never anticipated. I 
have been able to fix problems, enhance classes by creating subclasses with 
fixes and enhanced behavior. 

In java for example I have seen that sometimes I would have been able to fix 
bugs or enhance the existing classes had the author not chosen a method to be 
protected or private. Sometimes they had a good reason but sometimes they 
didn't.  Is have been able to survive using an awesome library that was 
discontinued and end-of-lifed thanks to subclassing that has allowed me to fix 
problems and enhance over the years as the Java language kept evolving. 

In general I like to design classes with methods that have a very well defined 
purpose / logic. Such methods are potentially overridable. I find that making a 
method private or final can be selfish / restrictive at times and I choose it 
carefully for implementation details that are better served by going through 
the public methods. 

I think that making a class not subclassable by default is restrictive / 
limiting / selfish. 

Sometimes the extension points are clear. 
I also think that every other method with a well defined purpose / logic is 
also potentially an extension point. 

In my experience we should allow the developer to override by default.  That is 
how I design my classes and every method / property. 

I use private for the stuff that is obvious that should not be exposed. 

In the motivation section performance is also mentioned as driving this 
proposal. However I don't see any study that supports that. I would like to see 
that. This should not be taken lightly. 

Let's imagine that performance is important for a library that is heavily used 
and that the classes are not the type that you usually override. Wouldn't we be 
better served  by being able to seal the class, i.e. "public sealed class Foo"  
and then for the methods / properties that are clear extension points should be 
flagged overridable.  I would prefer something like that. And I think it would 
be more intuitive. 


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

No. 

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

I think it is counter-intuitive. I don't think that reading "public class Foo" 
would make anyone think that Foo is non-subclassable. 

On the other hand, reading "public class sealed Foo" would suggest to the 
reader that the class can be overridden but only the methods that are flagged 
as overridable. 

If we wanted to prohibit overriding then we could use "public final class Foo" 
without any extension points. Then nobody would be able to subclass and it 
would be an error to try to flag a method / property as overridable.  


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

I don't recall having seen this behavior in the languages that I have worked 
with. 

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

I read the whole proposal and have been thinking about the implications for a 
few hours. 

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

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

[Max Moiseev via swift-evolution]

OptionSets do conform to AlgebraSet but they require raw value type to conform 
to BitwiseOperations.

Max

> On Jul 6, 2016, at 3:44 PM, Jordan Rose  wrote:
> 
> Option sets use set notation, not bitwise notation, no?
> 
> Jordan
> 
>> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution 
>>  wrote:
>> 
>> FixedWidthInteger only handles the implementation for the numbers, we should 
>> also consider OptionSet.
>> 
>> I think we should keep the protocol in case someone wants to implement their 
>> own type other than an integer to be used as a raw value type in the 
>> OptionSet.
>> 
>> As for renaming it, how about BitwiseOperand?
>> 
>> protocol BitwiseOperand {
>> func bitwiseOr(_ rhs: Self) -> Self
>> func bitwiseAnd(_ rhs: Self) -> Self
>> // etc ...
>> }
>> 
>> Max
>> 
>>> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Fri Jul 01 2016, Riley Testut  wrote:
>>> 
 Hi all,
 
 This is probably very minor, but I’m not sure the protocol name
 “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
 the guidelines have to say about protocol names:
 
 Protocols that describe what something is should read as nouns (e.g. 
 Collection).
 
 Protocols that describe a capability should be named using the
 suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
 
 From these two, BitwiseOperations appears to be (attempting) to follow
 the first rule, yet “BitwiseOperations” doesn’t really describe what
 the type is, but rather that it can do bitwise operations. The
 documentation itself even describes the protocol as “a type that
 supports standard bitwise arithmetic operators."
 
 I propose we rename it to “BitwiseOperable”, or something
 similar. Again, a small change, but if this were to ever happen, I
 think Swift 3 is the time.
>>> 
>>> BitwiseOperations should really be retired after
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>> is implemented, and its uses replaced by FixedWidthInteger.
>>> 
>>> -- 
>>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

[Jordan Rose via swift-evolution]

> On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 
> * Remove unsafeAddressOf. "We are not aware of any real use cases for it. If 
> there are any, it should be renamed to unsafeAddress(of:) to follow the 
> guidelines." (https://bugs.swift.org/browse/SR-1957 
>  rdar://problem/18589289 <>)
> 
> 
> Oops, I just responded to this on another thread. Pasting:
> 
> It's minor, but I use unsafeAddressOf regularly for writing `description` 
> methods:
> 
> var description: String {
> return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info 
> here... }"
> }
> 
> I guess this would be covered by some generalized solution for format 
> specifiers in string interpolations, but I gather that won't happen for quite 
> a while... 

I believe `ObjectIdentifier(self)` prints basically the same way.

Jordan

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

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

[Jordan Rose via swift-evolution]

Option sets use set notation, not bitwise notation, no?

Jordan

> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution 
>  wrote:
> 
> FixedWidthInteger only handles the implementation for the numbers, we should 
> also consider OptionSet.
> 
> I think we should keep the protocol in case someone wants to implement their 
> own type other than an integer to be used as a raw value type in the 
> OptionSet.
> 
> As for renaming it, how about BitwiseOperand?
> 
> protocol BitwiseOperand {
>  func bitwiseOr(_ rhs: Self) -> Self
>  func bitwiseAnd(_ rhs: Self) -> Self
>  // etc ...
> }
> 
> Max
> 
>> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Fri Jul 01 2016, Riley Testut  wrote:
>> 
>>> Hi all,
>>> 
>>> This is probably very minor, but I’m not sure the protocol name
>>> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>>> the guidelines have to say about protocol names:
>>> 
>>> Protocols that describe what something is should read as nouns (e.g. 
>>> Collection).
>>> 
>>> Protocols that describe a capability should be named using the
>>> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>>> 
>>> From these two, BitwiseOperations appears to be (attempting) to follow
>>> the first rule, yet “BitwiseOperations” doesn’t really describe what
>>> the type is, but rather that it can do bitwise operations. The
>>> documentation itself even describes the protocol as “a type that
>>> supports standard bitwise arithmetic operators."
>>> 
>>> I propose we rename it to “BitwiseOperable”, or something
>>> similar. Again, a small change, but if this were to ever happen, I
>>> think Swift 3 is the time.
>> 
>> BitwiseOperations should really be retired after
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>> is implemented, and its uses replaced by FixedWidthInteger.
>> 
>> -- 
>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

[Andrew Trick via swift-evolution]

> On Jul 4, 2016, at 7:52 PM, Jacob Bandes-Storch  wrote:
> 
> This is the first version of this proposal which I've had time to read. I 
> like it a lot overall. If I have some more time, I may try pulling the branch 
> and writing some code with it to see how it feels. (If we could get a 
> toolchain built from the branch, that might help others review it.)

The latest UnsafeRawPointer definition is on this branch:
https://github.com/atrick/swift/tree/rawptr

I plan to update it with the latest round of feedback soonish and send out a PR.
Unfortunately, the type system/stdlib changes are not on that branch, so you 
won't get any implicit conversions.

> Here are a handful of minor comments:
> 
> - Naming: "bindMemory(to:capacity:)", being "verb-ish", seems incongruous 
> with "assumingMemoryBound(to:)" and "withMemoryRebound(to:capacity:_:)". How 
> about "bindingMemory(to:capacity:)” ?

DaveA is right, "bind" is active, "assumingMemoryBound" is passive. 
"withMemoryRebound" temporarily rebinds the type and implies that the closure 
may mutate state.

> - Would it be possible for "+(UnsafeRawPointer, Int) -> UnsafeRawPointer" to 
> accept any Integer or FixedWidthInteger, rather than only Int?

I'm not sure what all the tradeoffs are, but I don't think we want to index 
memory with non-Int sized integers. I think the user should be required to 
convert, which may trap.

> - Why allow/encourage multiple calls to bindMemory on the same RawPointer? 
> These APIs do a good job of making aliasing explicit by introducing data 
> dependencies between pointers (you can only use a typed pointer after 
> obtaining it from a raw pointer, and you can recover the raw pointer for 
> later use by deinitializing the typed pointer). So, I would think the 
> guidelines should prefer bindMemory to be used only once on a particular 
> RawPointer value.

DaveA's answer was good. "bindMemory" is not really encouraged by the API. It's 
just mentioned a lot in the proposal because the semantics are interesting.

"bindMemory" is important because it's the only safe way to reinterpret 
in-memory values. So you need to use it to pass a UInt8 array off as a CChar, 
and so forth, which is actually quite common.

It is certainly encouraged more than unsafeBitCast(ptr, to: ...) because 
`bindMemory` is actually safe as long as you know the layout of the types and 
don't reuse your old typed pointers.

> And minor notes about the proposal itself:
> 
> - strideof(Int.self) is used in most examples, but sizeof(Int.self) appears 
> in one of them (the "normalLifetime()" example).

That example is actually allocating memory for a single value. Should it be 
changed to `strideof`? If so, then what's the point of `sizeof`?

> - I think there must be a mistake in this example, because pA is already 
> bound and bindMemory was only defined for untyped RawPointers:
> 
> func testInitAB() {
>   // Get a raw pointer to (A, B).
>   let p = initAB()
> 
>   let pA = p.bindMemory(to: A.self, capacity: 1)
>   printA(pA)
> 
>   printB((pA + 1).bindMemory(to: B.self, capacity: 1))   //<<< should 
> this be (p+1) rather than (pA+1)?
> }

Thanks. That was supposed to be cast to raw pointer like the other examples:

  // Knowing the `B` has the same alignment as `A`...
  printB(UnsafeRawPointer(pA + 1).bindMemory(to: B.self, capacity: 1))

-Andy

> 
> Jacob
> 
> On Mon, Jul 4, 2016 at 3:32 PM, Andrew Trick via swift-evolution 
> > wrote:
> 
>> On Jun 28, 2016, at 11:05 PM, Chris Lattner > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through 
>> July 4, 2016. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>>  
>> 
> 
> 
> I've revised the proposal again based on extremely helpful feedback from 
> DaveA and Jordan.
> 
> This revision expands on the concept of formally binding the memory type that 
> I was recently working on with Dmitri. Now we can clearly define pre and post 
> conditions on memory operations and pointer casts that can be used to prove 
> the type safety. The model is now simpler, more complete, and easy to reason 
> about locally. This will help developers reason about correctness and make it 
> easy to implement a sanitizer that verifies the type safety of UnsafePointer 
> operations.
> 
> Adding safety to pointer "casts" made it possible for me to actually simplify 
> the allocation and initialization APIs. I think both camps, convenience and 
> safety, will be happy.
> 
> You can see what changed in this pull request:
> https://github.com/apple/swift-evolution/pull/408 
> 
> 
> Brief 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 2:47 PM, Matthew Johnson  wrote:
> 
> This is not true.  Public classes will *not* be “final by default”.  It 
> *will* be possible to subclass them within their declaring module.  If they 
> need to be final they will still need to be marked as such.  
> 
> With that in mind, the your “can override” column (do you really mean “can 
> subclass” here?) is also not correct.  The correct answer is “yes, within the 
> module”.  The fundamental difference for this row is that there are some 
> scopes which can *see* the type without the ability to subclass it.  There is 
> no problem with this, it is *exactly* what we want.  

So would this be more accurate?

  access  | can access| can subclass/  | final
  |   | override where |
 -+---++---
  open| all scopes| all scopes | Error
  public  | all scopes| within module  | final
  internal| within module | within module  | final
  fileprivate | within file   | within file| final
  private | within scope  | within scope   | final

> The purpose of this proposal is precisely to give library authors the ability 
> to have more fine grained control over what capabilities their library 
> exposes to users.
> 

I don’t have an issue with the purpose, I have an issue with doing it by 
conflating access control and finality, and making the language confusing as a 
result.

Assuming the above table matches your expectation, compare it with the same 
matrix for the language as it is today:

  access  | can access| can subclass/  | final
  |   | override where |
 -+---++---
  public  | all scopes| all scopes | final
  internal| within module | within module  | final
  fileprivate | within file   | within file| final
  private | within scope  | within scope   | final

The existing table is clean, it’s easy to understand; the two concepts are 
entirely separate from each other. The access control keyword defines where a 
class, method, property, or subscript can be accessed from; the `final` keyword 
defines whether or not it can be subclassed or overridden.


To give you an example of the confusion, here is code made perfectly legal by 
SE-0025:

  public final class Example {

overridable func foo() {}

  }

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

> On Jul 6, 2016, at 4:36 PM, Scott James Remnant via swift-evolution 
>  wrote:
> 
> 
>> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa > > wrote:
>> 
>> You can also try and simplify your outlines reducing X.c and X.d to a
>> single entry as it is the same rule applied to two different elements
>> of the language. Using one single keyword (such as in 'open') would
>> make it clearer and that is why I prefer to have only one keyword.
>> 
> 
> I didn’t simply the outlines precisely because the proposal suggests two 
> keywords.
> 
> One keyword does solve this problem, but not the problem of conflation of 
> finality and access control.
> You end up with this matrix:
> 
>   access  | can override | final
>  -+--+---
>   open| yes  | Error - “class cannot be open and final”

Of course this produces a compile error.  Open means “can subclass” which 
directly contradicts final.

>   public  | no   | Error - “public class is already final by 
> default”

This is not true.  Public classes will *not* be “final by default”.  It *will* 
be possible to subclass them within their declaring module.  If they need to be 
final they will still need to be marked as such.  

With that in mind, the your “can override” column (do you really mean “can 
subclass” here?) is also not correct.  The correct answer is “yes, within the 
module”.  The fundamental difference for this row is that there are some scopes 
which can *see* the type without the ability to subclass it.  There is no 
problem with this, it is *exactly* what we want. 

The purpose of this proposal is precisely to give library authors the ability 
to have more fine grained control over what capabilities their library exposes 
to users.

>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
> 
> This is way more confusing than the current language:
> 
>   access  | can override | final
>  -+--+---
>   public  | yes  | final
>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
> 
> I strongly favor a programming language that doesn’t introduce compiler 
> errors to solve problems that could be solved by cleaner syntax.
> 
> Since it’s already necessary to place the `public` keyword in front of every 
> class, method, property, or subscript that you intend to make public, the 
> developer is already thinking about the public API. Typing `public final` 
> instead of `public` is an extra keyword, it’s not an extra cognitive burden 
> since that cognition is already taking place.

As you can see from the points above, `public final` is something very 
different than both `public` and `public subclass able` (or `open`) under the 
current proposal.  It is not a question of cleaner syntax.  It is a question of 
whether we want to give library authors more fine grained control.

-Matthew

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

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I don't disagree with you on 'fileprivate' and 'private' being
unnecessary and we may stick to the proposal at hand and leave the
'final' issue to another proposal, should anyone else care (I myself
don't mind if it sticks around - just have to not use it).

As for the conflict, I don't see it. Can you declare a 'public private
class'? I think it is just the same with 'open' and 'final'. And there
is no need to introduce an error for being redundant with 'public
final' either.

L

On 6 July 2016 at 18:36, Scott James Remnant  wrote:
>
> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa  wrote:
>
> You can also try and simplify your outlines reducing X.c and X.d to a
> single entry as it is the same rule applied to two different elements
> of the language. Using one single keyword (such as in 'open') would
> make it clearer and that is why I prefer to have only one keyword.
>
>
> I didn’t simply the outlines precisely because the proposal suggests two
> keywords.
>
> One keyword does solve this problem, but not the problem of conflation of
> finality and access control.
> You end up with this matrix:
>
>   access  | can override | final
>  -+--+---
>   open| yes  | Error - “class cannot be open and final"
>   public  | no   | Error - “public class is already final by
> default"
>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
>
> This is way more confusing than the current language:
>
>   access  | can override | final
>  -+--+---
>   public  | yes  | final
>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
>
> I strongly favor a programming language that doesn’t introduce compiler
> errors to solve problems that could be solved by cleaner syntax.
>
> Since it’s already necessary to place the `public` keyword in front of every
> class, method, property, or subscript that you intend to make public, the
> developer is already thinking about the public API. Typing `public final`
> instead of `public` is an extra keyword, it’s not an extra cognitive burden
> since that cognition is already taking place.
>
> Scott
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 6, 2016, at 1:41 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> Sent from my iPhone
> 
>> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution 
>>  wrote:
>> 
>> In the era of increased open sourcing, easy forking, and more 
>> community-driven development, this concern is less severe than it used to 
>> be. I rarely use any closed-sourced libraries for iOS development. If I need 
>> to tweak some library and non-subclassibility is getting in the way, then I 
>> can fork it — and perhaps even contribute my changes back to improve the 
>> upstream project. In an open source world, “closed by default” makes a lot 
>> more sense.
> 
> Maintaining a fork, realistically often without hope of upstream merging, 
> your changes is feels like a very business unfriendly idea and less scalable 
> than it sounds in many environments.
> 
> I see closed by default as part of the movement some people seem to be 
> embracing of opt-out model in which freedom and versatility is forcefully 
> restrained, making the language more complex and exotic/breaking conventions 
> for the sake of protecting people from themselves, instead of opt-in models 
> which require programmers to be diligent and know when to constrain 
> themselves while enjoying more flexible defaults.
> I am not asking for JavaScript, but I do not want this language to go the 
> complete polar opposite, more dogmatic than C++ or Java.

This proposal is specifically targeting library interfaces.  It's not a 
slippery slope towards locking things down at a sub-library level because (1) 
we've already considered and rejected the analogous sub-library-level proposal 
(as "final by default") and (2) almost all of the justifications are tied to 
the specific problems that arise with library interfaces.

In general, Swift already treats library interfaces as a special point at which 
a lot of considerations change.  The most prominent example of that is access 
control, but there are a lot of other examples that will become more apparent 
as we complete the resilience model, solidify the ABI, and start really 
supporting binary distribution of libraries.  The basic idea is that library 
designers face a set of language problems that other programmers don't, and the 
language ought to understand that and provide a different set of features and 
defaults.  This is a language design that's made possible by Swift's relatively 
strong commitment to defining and enforcing library boundaries, as opposed to 
the languages you list.  To me, this is a great way to only get dogmatism when 
it's actually useful and necessary.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa  wrote:
> 
> You can also try and simplify your outlines reducing X.c and X.d to a
> single entry as it is the same rule applied to two different elements
> of the language. Using one single keyword (such as in 'open') would
> make it clearer and that is why I prefer to have only one keyword.
> 

I didn’t simply the outlines precisely because the proposal suggests two 
keywords.

One keyword does solve this problem, but not the problem of conflation of 
finality and access control.
You end up with this matrix:

  access  | can override | final
 -+--+---
  open| yes  | Error - “class cannot be open and final"
  public  | no   | Error - “public class is already final by 
default"
  internal| yes  | final
  fileprivate | yes  | final
  private | yes  | final

This is way more confusing than the current language:

  access  | can override | final
 -+--+---
  public  | yes  | final
  internal| yes  | final
  fileprivate | yes  | final
  private | yes  | final

I strongly favor a programming language that doesn’t introduce compiler errors 
to solve problems that could be solved by cleaner syntax.

Since it’s already necessary to place the `public` keyword in front of every 
class, method, property, or subscript that you intend to make public, the 
developer is already thinking about the public API. Typing `public final` 
instead of `public` is an extra keyword, it’s not an extra cognitive burden 
since that cognition is already taking place.

Scott

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa  wrote:
> 
> So I did get what you meant right. Now tell me: if a class or method
> is internal to your module (and you know internal means only you,
> throught your source code, inside your app or library can extend it),
> do you really need to mark anything as final for any reason? Final on
> any non-publics is a restriction you put on yourself, you will always
> have the power to lift that at any time (as long as you still own the
> code, of course) so you are always in control of your subclasses and
> overrides. All the time. It's up to you to subclass/override or not.
> This is different from what you make public: you either have no
> control or you have to fine grain control making everything final. You
> regain that control over your publics with this proposal.
> 

The same argument could be applied to why we have `fileprivate` and `private`, 
if a class or method is internal to my module, why do I need to mark anything 
as further private for any reason?

There are a whole bunch of answers; perhaps the module is maintained by a team 
of twenty people, and the class is intended to be sub-classed within the team, 
so it’s a level of “internal public.” It doesn’t even have to be a team, maybe 
I’m writing a utility class that I know I’ll use for years, and I know I’ll 
forget my rationale later down the line and make the mistake of overriding 
something I shouldn’t.

Removing `final` is a whole proposal unto itself that I would also -1, it’s not 
covered by this one, so at this point this is a rabbit hole.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[David Rönnqvist via swift-evolution]

>   * What is your evaluation of the proposal?

+1 (almost exclusively)

Writing good library code is hard and a lot of code isn't actually written to 
be externally subclasses (and trying to plan for subclassing can be difficult). 
Our team also writes "final class" in a lot of places and I don't like it (but 
wouldn't want final by default either).

This proposal feels like a sensible trade off to me. Having to intentionally 
mark classes for public subclassability leads to better safety (only classes 
being intended for external subclassing actually being subclassable), clarity 
(by documenting what's designed for subclassing/overriding), performance (by 
enabling optimizations if a class isn't subclasses internally) while still 
providing convenience within the module (enabling the authoring team to 
subclass and not having to put final throughout).

There is some negative with regards to limiting the ability to patch third 
party code, but I think the benefits of this proposal are worth that.

The behavior of Objective-C classes and @testablity are an important part of 
this proposal.

Bike sheding:

The subclassable/overridable pair read well on their own but it's not obvious 
to me that subclassable is also public and that it's not needed internally. 
This could be helped by requiring "subclassable" classes to also be marked 
"public" and making it an error to declare a class as "internal subclassable" 
or "private subclassable" (all 3 could have a simple fix-it).

I would also be fine with either "open" or "extensible" (although I could see 
"extensible" being interpreted as "can have extensions" instead of "can be 
subclasses").

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

Yes. Being safe by default is well aligned with Swift. I would also argue that 
the same applies to being explicit about the authors intentions where it's 
needed. 

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

None. Objective-C is completely open and I can't recall any other language that 
differentiates between "public" and "public subclassable".

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


Read the proposal and the review feedback so far.

- David

> On 6 Jul 2016, at 01:11, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell via swift-evolution]

> On Jul 6, 2016, at 3:41 PM, Goffredo Marocchi  wrote:
> 
>> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution 
>>  wrote:
>> 
>> In the era of increased open sourcing, easy forking, and more 
>> community-driven development, this concern is less severe than it used to 
>> be. I rarely use any closed-sourced libraries for iOS development. If I need 
>> to tweak some library and non-subclassibility is getting in the way, then I 
>> can fork it — and perhaps even contribute my changes back to improve the 
>> upstream project. In an open source world, “closed by default” makes a lot 
>> more sense.
> 
> Maintaining a fork, realistically often without hope of upstream merging, 
> your changes is feels like a very business unfriendly idea and less scalable 
> than it sounds in many environments.

It certainly has its problems, but in practice it’s no worse than brittle 
workarounds such as unintended subclassing.

In the case of forking, upgrading a library comes with the cost of merging 
changes. In the case of brittle subclassing, upgrading a library comes with the 
cost of your patches suddenly breaking. In either case, you have a body of code 
which is tightly coupled to an external library in ways that the library's 
author isn’t monitoring for breakage.

In my experience, forking is usually the less costly route because it gives 
more control. Modern version control makes maintaining a fork over time much 
easier than it used to be — and the ever-improving social dynamics of pull 
requests make forks less likely to live on forever.

Cheers,

Paul

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

So I did get what you meant right. Now tell me: if a class or method
is internal to your module (and you know internal means only you,
throught your source code, inside your app or library can extend it),
do you really need to mark anything as final for any reason? Final on
any non-publics is a restriction you put on yourself, you will always
have the power to lift that at any time (as long as you still own the
code, of course) so you are always in control of your subclasses and
overrides. All the time. It's up to you to subclass/override or not.
This is different from what you make public: you either have no
control or you have to fine grain control making everything final. You
regain that control over your publics with this proposal.

You can also try and simplify your outlines reducing X.c and X.d to a
single entry as it is the same rule applied to two different elements
of the language. Using one single keyword (such as in 'open') would
make it clearer and that is why I prefer to have only one keyword.

So, AFAICS, number 3 is how it should be with this proposal. As for
keeping the final keyword (sticking with number 2), I think it is up
to the community. I myself don't see any reason/need for it should
this proposal pass.

L

On 6 July 2016 at 17:32, Scott James Remnant  wrote:
>>
>> On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa  wrote:
>>
>> Scott, I think your writing got a bit confuse but, if I got your
>> intention right, since you are the owner of the class, you may choose
>> to subclass it or not internally, no questions asked.
>
> No.
>
> This is how the language exists today:
>
> 1a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 1b. All classes may be subclassed, and all methods, properties, and 
> subscripts overridden. This can be prevented by adding the `final` keyword.
>
> The two concepts are very separate, and I think this is a good thing.
>
>
> What this proposal suggests, whether or not `final` is kept or removed, is 
> that the two concepts become conflated:
>
> 2a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 2b. Non-`public` classes may be subclassed, and non-`public` methods, 
> properties, and subscripts overridden. This can be prevented by adding the 
> `final` keyword.
>
> 2c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 2d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> Removing the `final` keyword means a change to 2b above. The first option is 
> simply to throw it away, in which case you end up with:
>
> 3a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 3b. Non-`public` classes may be subclassed, and non-`public` methods, 
> properties, and subscripts overridden. This can be never be prevented.
>
> 3c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 3d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> The second option is to throw it away, and adjust the default behavior so it 
> truly is `final` as removing the keyword would imply. Then you end up with:
>
> 4a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 4b. Non-`public` classes may not be subclassed, and non-`public` methods, 
> properties, and subscripts may not be overridden. This can never be allowed.
>
> 4c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 4d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> To me all of these options take a clean, easy-to-understand, language design 
> (1) and turn it into various states of mess. Removing the `final` keyword not 
> only makes it a mess, but removes functionality—the ability to have a mix of 
> final and non-final classes, methods, properties, and subscripts, accessible 
> only within your own module.
>
> Scott
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Dropping Comparable requirement for indices

[Haravikk via swift-evolution]

> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution 
>  wrote:
> For example, with
> Comparable indices, you can't build a linked list that supports
> restructuring (e.g. insert, delete, splice) in O(1) without invalidating
> indices... not even an unsafe linked list with reference semantics.

I think the question is why you need to retain indices in these cases?

When it comes to these operations I wonder if we might want to investigate 
something like a mutating iterator; you might still use an index to jump to an 
initial position, but then use .insert(), .remove() etc. methods of the 
iterator to perform modification without the need to track indices at all. This 
is essentially how you want to edit trees anyway, as indexing them isn't 
especially pretty, as it avoids the need to track the indices at all for these 
operations, and many common cases should work well when done as part of an 
iterator in this way.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution 
>  wrote:
> 
> In the era of increased open sourcing, easy forking, and more 
> community-driven development, this concern is less severe than it used to be. 
> I rarely use any closed-sourced libraries for iOS development. If I need to 
> tweak some library and non-subclassibility is getting in the way, then I can 
> fork it — and perhaps even contribute my changes back to improve the upstream 
> project. In an open source world, “closed by default” makes a lot more sense.

Maintaining a fork, realistically often without hope of upstream merging, your 
changes is feels like a very business unfriendly idea and less scalable than it 
sounds in many environments.

I see closed by default as part of the movement some people seem to be 
embracing of opt-out model in which freedom and versatility is forcefully 
restrained, making the language more complex and exotic/breaking conventions 
for the sake of protecting people from themselves, instead of opt-in models 
which require programmers to be diligent and know when to constrain themselves 
while enjoying more flexible defaults.
I am not asking for JavaScript, but I do not want this language to go the 
complete polar opposite, more dogmatic than C++ or Java.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Tino Heth via swift-evolution]

> If you have a ParentClass and a SubClass, and the ParentClass is sealed while 
> the SubClass is subclassable. What happens? No matter how this question is 
> answered, I don't like the answer. (compile error => bad. || make it as the 
> user wishes => bad; what do we gain by letting ParentClass remain sealed? || 
> make ParentClass implicitly subclassable too => bad.)
I'm happy that there are not only supporters for this proposal, but imho the 
example is no compelling argument:
With no doubt, I'd expect I can subclass only SubClass — like I can't 
instantiate an abstract class, which is just fine for its children.
ParentClass might do some dangerous things that don't happen in SubClass, so 
there might even be a use-case (but imho it would be better if I could mark 
ParentClass as internal in this situation).

But imho there is another aspect I haven't read about yet:
"final by default" would have had direct impact on any developer, while this 
proposal merely changes things for those who create libraries…
So, the question is: How will those be build?

If you live in a world of secrets and non-disclosure, I can understand that 
sealed is desirable — but that's not the future I want to see, and github is a 
good indication that others share this opinion.

If you share the sympathy for Open source, the two scenarios are as follows:
We stick with "open by default"; users of libraries will use them in ways that 
the creator hasn't thought of before, and bugs will show up.
But: We know how to deal with bugs, that's our job! So in the best case, we 
find the reason for the bad behavior, create a pull request, and everyone is 
happy.

With "sealed by default", the situation changes:
Users are protected from some simple bugs, but nonetheless, they'll encounter 
situations where the library doesn't do exactly what they want.
So, you take a look at the source, find the problem, and fix it.
It's no bug at all, it's just a tiny degree of freedom that is missing because 
it wasn't important to the author.
You can create a pull request as well, but it doesn't offer a real improvement 
to the author, who is already busy with dozens of similar requests by other 
users -> you end up with a custom branch with all the housekeeping associated 
with it.

So overall, I'm quite sure that the proposal won't improve software quality, 
but rather degrade it.

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

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

[David Rönnqvist via swift-evolution]

>* What is your evaluation of the proposal?

+1. I find this to be a solid, well reasoned proposal. 

I enjoyed seeing such a detailed Motivation and am looking forward to 
discussing the Related Proposals and Future Directions mentioned in this one.

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

Yes. Interoperability between Objective-C and Swift remains important and we 
don't want to be held back from creating the best possible Swift experience.

>* 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'm not familiar with (haven't used) libraries that bridge across languages 
without exposing the same types with the same naming and behaviors in both 
languages.

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

Read the proposal

- David

> On 5 Jul 2016, at 17:45, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0116: Import Objective-C id as Swift Any type" begins now 
> and runs through July 11. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> 
> On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa  wrote:
> 
> Scott, I think your writing got a bit confuse but, if I got your
> intention right, since you are the owner of the class, you may choose
> to subclass it or not internally, no questions asked.

No.

This is how the language exists today:

1a. Default access control is `internal`, and may be modified by adding the 
`public`, `fileprivate`, or `private` keyword, as appropriate.

1b. All classes may be subclassed, and all methods, properties, and subscripts 
overridden. This can be prevented by adding the `final` keyword.

The two concepts are very separate, and I think this is a good thing.


What this proposal suggests, whether or not `final` is kept or removed, is that 
the two concepts become conflated:

2a. Default access control is `internal`, and may be modified by adding the 
`public`, `fileprivate`, or `private` keyword, as appropriate.

2b. Non-`public` classes may be subclassed, and non-`public` methods, 
properties, and subscripts overridden. This can be prevented by adding the 
`final` keyword.

2c. `public` classes may not be subclassed. To allow this replace the `public` 
keyword with `subclassable`

2d. `public` methods, properties, and subscripts may not be overridden. To 
allow this replace the `public` keyword with `overiddable`.


Removing the `final` keyword means a change to 2b above. The first option is 
simply to throw it away, in which case you end up with:

3a. Default access control is `internal`, and may be modified by adding the 
`public`, `fileprivate`, or `private` keyword, as appropriate.

3b. Non-`public` classes may be subclassed, and non-`public` methods, 
properties, and subscripts overridden. This can be never be prevented.

3c. `public` classes may not be subclassed. To allow this replace the `public` 
keyword with `subclassable`

3d. `public` methods, properties, and subscripts may not be overridden. To 
allow this replace the `public` keyword with `overiddable`.


The second option is to throw it away, and adjust the default behavior so it 
truly is `final` as removing the keyword would imply. Then you end up with:

4a. Default access control is `internal`, and may be modified by adding the 
`public`, `fileprivate`, or `private` keyword, as appropriate.

4b. Non-`public` classes may not be subclassed, and non-`public` methods, 
properties, and subscripts may not be overridden. This can never be allowed.

4c. `public` classes may not be subclassed. To allow this replace the `public` 
keyword with `subclassable`

4d. `public` methods, properties, and subscripts may not be overridden. To 
allow this replace the `public` keyword with `overiddable`.


To me all of these options take a clean, easy-to-understand, language design 
(1) and turn it into various states of mess. Removing the `final` keyword not 
only makes it a mess, but removes functionality—the ability to have a mix of 
final and non-final classes, methods, properties, and subscripts, accessible 
only within your own module.

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

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

[Max Moiseev via swift-evolution]

FixedWidthInteger only handles the implementation for the numbers, we should 
also consider OptionSet.

I think we should keep the protocol in case someone wants to implement their 
own type other than an integer to be used as a raw value type in the OptionSet.

As for renaming it, how about BitwiseOperand?

protocol BitwiseOperand {
  func bitwiseOr(_ rhs: Self) -> Self
  func bitwiseAnd(_ rhs: Self) -> Self
  // etc ...
}

Max

> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Jul 01 2016, Riley Testut  wrote:
> 
>> Hi all,
>> 
>> This is probably very minor, but I’m not sure the protocol name
>> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>> the guidelines have to say about protocol names:
>> 
>> Protocols that describe what something is should read as nouns (e.g. 
>> Collection).
>> 
>> Protocols that describe a capability should be named using the
>> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>> 
>> From these two, BitwiseOperations appears to be (attempting) to follow
>> the first rule, yet “BitwiseOperations” doesn’t really describe what
>> the type is, but rather that it can do bitwise operations. The
>> documentation itself even describes the protocol as “a type that
>> supports standard bitwise arithmetic operators."
>> 
>> I propose we rename it to “BitwiseOperable”, or something
>> similar. Again, a small change, but if this were to ever happen, I
>> think Swift 3 is the time.
> 
> BitwiseOperations should really be retired after
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
> is implemented, and its uses replaced by FixedWidthInteger.
> 
> -- 
> 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] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell via swift-evolution]

> * What is your evaluation of the proposal?

+1, with bikeshedding.

To me, “subclassable” does not imply “public.” If I hadn’t read this proposal, 
I would be likely to declare an internal class subclassable, and then be 
shocked when it was exposed as public!

If it’s part of my public API, I want to see the word “public” on it. That 
should not be implicit under any circumstances. I strongly prefer any one of 
these to the standalone “subclassable:”

• public(subclassable)
• public(open)
• public(extensible)

The extra verbosity is tolerable because subclassability by design is (should 
be!) the exception, not the rule.

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

Yes, it fits two patterns of Swift’s general design:

if one choice is the default, it is the safer one; and
consequential design decisions are explicit. Implicitness is reserved for 
obvious / redundant information that becomes noise and interferes with 
readability.

To that end…

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

…open public classes run against general precedent in the language, so yes.

As programmers grow used to Swift, they will increasingly lean on the compiler 
to prompt them when there is an important type design issue to consider, or 
when they are doing something that compromises type safety. The absence of a 
compiler warning becomes important information.

This means that making open classes the default is not just aesthetically 
suboptimal; it is actively misleading.

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

No. In all the OO languages I’ve used, classes are open by default. That raises 
a question: is this really a good idea? Aren’t we ignoring established 
precedent? What about all the unauthorized subclassing we’ve done in the past?

I’m sympathetic to those accustomed to Objective-C, Ruby, Javascript, Python, 
and other languages with more fungible type systems who argue that it’s 
unreasonable to expect us all to use classes only as library authors intend. 
Monkey patching has saved many a day, they’d say. And it’s true, it has! I rely 
on it.

My counterargument: the ecosystem is changing.

In the era of increased open sourcing, easy forking, and more community-driven 
development, this concern is less severe than it used to be. I rarely use any 
closed-sourced libraries for iOS development. If I need to tweak some library 
and non-subclassibility is getting in the way, then I can fork it — and perhaps 
even contribute my changes back to improve the upstream project. In an open 
source world, “closed by default” makes a lot more sense.

The big exception to this is Apple itself, and the direction of this proposal 
implies a large cultural shift in how Apple deals with its developer community. 
Having the Swift language so aggressively prevent the dubious, brittle, 
bad-idea-but-it-gets-the-job-done workarounds that the Obj-C runtime allowed 
means that Apple’s platforms are going to have to be more consciously 
extensible, more transparent in their design decisions, and more responsive to 
unanticipated needs. This community right here is an exemplar.

Here’s thing: this big shift goes far, far beyond this proposal. Swift already 
rules out most any form of messing with a library’s assumptions about its own 
design. With or without the proposal, Apple is already getting on board with 
the new regime of stricter typing and more hermetically sealed libraries. 
They’re already going to have to make API design decisions about how and where 
extensibility is allowed with unprecedented caution.

This proposal hardly alters that tipping balance; it just removes a design 
inconsistency.

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

I read the proposal carefully, the discussion thread not at all.

Cheers,

Paul

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Scott, I think your writing got a bit confuse but, if I got your
intention right, since you are the owner of the class, you may choose
to subclass it or not internally, no questions asked. I need no finals
in my apps and I only subclass if I intend to. If you are in control
of your own code, why would you need to ensure there would be no
subclassing/overriding? I'm not opposed to keeping the keyword if it
is important to anyone to be sure of that for internals. As for what
is public you will gain better control of what other people do to your
classes and methods.

L

On 6 July 2016 at 16:56, Scott James Remnant  wrote:
>
>> On Jul 6, 2016, at 12:50 PM, Leonardo Pessoa  wrote:
>>
>> Scott, you really got a point here: should this proposal pass, I
>> believe the final keyword should be removed as it would be already the
>> default behaviour and thus unnecessary. I don't think this is on the
>> proposal.
>>
>
> Removing the `final` keyword would mean there would be no way to have a class 
> of `internal` (default) scope that subclasses and another class of `internal` 
> (default) scope and overrides a method of `internal` (default) scope.
>
> Scott
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing Variadic Parameters.

[David Rönnqvist via swift-evolution]

I'd be reluctant to remove variadic parameters. We've found on our team that 
variadic arguments are easier to read on the call site compared to array 
arguments, especially when it's common to pass a single value (but still 
possible to pass multiple values).

- David

> On 6 Jul 2016, at 20:38, Tino Heth via swift-evolution 
>  wrote:
> 
> It's a late answer… but I wanted to be a good citizen and checked if the 
> topic has been discussed before; so, it seems that is not the case ;-)
> 
> In short, I agree:
> Variadic parameters are somewhat cool, and I think I was exited when I've 
> seen them in C the first time… but I afair, I never created a variadic 
> function in production code, and I think I just used them for the first time 
> in Swift (I checked wether print is variadic…)
> As of today, string interpolation has several advantages over old-style 
> string-formatting, and I can't remember any other method in one of the 
> established libraries that uses this feature:
> Explicitly creating an array is just two additional characters, which doesn't 
> matter in a long list (which imho shouldn't be crammed into the function call 
> anyways), and when there are only a few parameters, you can mimic variadics 
> with Optionals defaulted to nil — and who knows what the long-awaited 
> hygienic macros might do to the importance of variadic parameters.
> 
> Additionally, variadic parameters compete with trailing closures, which for 
> me would always win the struggle for the last parameter ;-)
> 
> As I said, I can't remember a single use case in Swift — and I already 
> utilized quite a lot of the "strange" techniques (currying, tuple splat, 
> complicated combinations of generics & protocols…).
> So for me, the answer to the question "would I add this feature to Swift if 
> it wasn't there?" is a clear no…
> 
> Tino
> ___
> 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-0117: Default classes to be non-subclassable publicly

[Sean Heber via swift-evolution]

> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 

I posted this somewhere else in another thread, but I still think a slightly 
different approach to all of the access namings might make more sense:

- everything is “sealed" within its module by default, no keyword for this

- use “export” (formerly “public”) to mean “visible outside of the module, no 
subclassing or overriding externally, but overriding and subclasses allowed 
internally unless otherwise restricted”

- use “export(public)” to mean “visible outside of the module, can be 
subclassed or overridden externally”

- “export final” means that the class/method is also final within its own module

- using “export(public) final” *probably* doesn’t make sense, but would mean 
overriding/subclasses allowed externally, but not internally

My argument for “export” here is that it is the logical inverse of “import” 
which is how you get another module’s stuff into your module in the first place.

Then I would want to consider a rename of “internal” to “public” and 
“fileprivate” to “internal” so the complete list would be:

export - accessible outside of the module
public - accessible anywhere within the module
private - accessible only within the scope 
internal - accessible within the same source file

In this way, there is nice symmetry between import/export, and then again 
between public/private. The source-file-based grouping of “internal” now has a 
name that is more unique and not immediately related to the other access 
keywords, either, which makes sense since it’s on a slightly different axis.

After all of this, the “export(public)” case rational would seem to be logical 
- you’re saying that the symbol is accessible outside of *this* module and 
subclassable/overridable within the “public” context of whatever module is 
importing it - hence using both “export” and “public”.

So anyway, I don’t know if this counts as a -1 vote or not or if this is even 
coherent, but this is my feedback at the moment. :)

l8r
Sean

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

Re: [swift-evolution] Removing Variadic Parameters.

[Tino Heth via swift-evolution]

> I believe variadic parameters are useful in a range of situations and
> I use them myself a lot.
Can you talk about concrete examples? Because Objective-C had no variadic 
messages, it's natural that the feature isn't utilized in Cocoa, but I doubt 
that it is used by many native Swift libraries either.

I'm the last one to take away something that doesn't hurt, but so far, several 
(in my opinion) useful features have been removed with the option to 
reintroduce them later — and at least tuple splat really had unique aspects 
(compared to variadics, which are just a small dose of syntactic sugar).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

> On Jul 6, 2016, at 12:50 PM, Leonardo Pessoa  wrote:
> 
> Scott, you really got a point here: should this proposal pass, I
> believe the final keyword should be removed as it would be already the
> default behaviour and thus unnecessary. I don't think this is on the
> proposal.
> 

Removing the `final` keyword would mean there would be no way to have a class 
of `internal` (default) scope that subclasses and another class of `internal` 
(default) scope and overrides a method of `internal` (default) scope.

Scott

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 6, 2016, at 12:35 PM, Leonardo Pessoa via swift-evolution 
>  wrote:
> Intention.
> 
> IMO, intention may lead to more secure systems (and libraries). By
> having to explicitly final everything I have to choose with parts of
> my class/library would be locked and have to worry and check if any
> public thing could be used to exploit it or make the system work in a
> way I did not intended to. Also, final will prevent anyone including
> me from extending/overriding. Defaulting to final would require from
> me to explicitly declare the open endpoints in my libraries, so I
> could explicitly open only the ones that are really intended to be
> used in that way by third-parties.
> 
> As an example, I'm working on a system which has an internal
> representation of Files and Folders using a common superclass (lets
> call it Entry). I would like for other developers to be able to create
> new entry types (not only inheriting from File) but I do not wish for
> them to extend from Folder or any of its subclasses (specialised
> folders). By using final I can prevent others from extending my Folder
> but I cannot extend it myself and thus need another mechanism for
> achieving this behaviour without bloating the Folder class with all
> its specialisations. This proposal would allow me to make my Folder
> and its subclasses publicly available/usable but would prevent others
> from subclassing and thus misusing them in ways I did not intend them
> to. The same rationale applies to methods.

I would underline this and add that the "final" workflow doesn't work very well
for methods.  You've started with a final class, but now you want to allow
subclasses, so you remove the "final"... and now you have to carefully
add it back to every method and property on your class, because the default
is non-final.  And every time you modify the class in the future, you have to
remember to think about "final" for everything you add.  Forbidding external
overrides is the safer default assumption.

The default is also better for programmers using the library, because the
class author's intent is much clearer.  I've maintained plenty of OO code where
subclassers weren't sure how they were supposed to customize the behavior
of the superclass, and so they just overrode a ton of different methods and 
repeated
the same logic in every place instead of using the already-defined extension
points (or asking for a new one).  Result: an unmaintainable subclass and a
superclass that can't be changed without breaking everything.

John.

> 
> L
> 
> On 6 July 2016 at 16:09, Goffredo Marocchi  wrote:
>> Leonardo, how is defaulting to final/sealed helping you write better 
>> libraries than having a final keyword for what you need to close instead?
>> 
>> Sent from my iPhone
>> 
>> On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution 
>>  wrote:
>> 
 The review of "SE-0117: Default classes to be non-subclassable publicly" 
 begins now and runs through July 11. The proposal is available here:
 
   
 https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
 
   * What is your evaluation of the proposal?
>>> 
>>> +1. Being able to control how a class from my libraries are going to
>>> be used by third-parties could enable a better designed API with more
>>> control of how it is intended to be used. I'm just not fond of using
>>> the proposed keywords ('subclassable' and 'overridable') as they feel
>>> more like protocol or attribute names; I'd be more inclined to use the
>>> alternative 'public open' instead, or 'public(open)' as a second
>>> option.
>>> 
   * Is the problem being addressed significant enough to warrant a 
 change to Swift?
>>> 
>>> I'd say it is significant to every language.
>>> 
   * 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?
>>> 
>>> C# uses the keyword 'virtual' to explicitly mark methods that can be
>>> overriden (not considered in the alternatives but I'm not a big fan of
>>> it).
>>> 
   * How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
>>> 
>>> I've took (a small) part on the thread discussing this proposal but
>>> followed it closely
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Scott, you really got a point here: should this proposal pass, I
believe the final keyword should be removed as it would be already the
default behaviour and thus unnecessary. I don't think this is on the
proposal.

L

On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution
 wrote:
> -1
>
> This proposal makes Swift a more confusing language.
>
>
> Swift already has a mechanism for creating public subclassable classes and
> non-subclassable classes:
>
>   public class SubclassableParentClass { }
>
>   public final class NonSubclassableParentClass { }
>
> This mechanism also applies to methods, properties, and subscripts:
>
>   public func bar() {}
>
>   public final func foo() {}
>
> The proposal makes no effort to remove this existing syntax.
>
> The very fact that this would be legitimate syntax as a result is a bad omen
> to me:
>
>   subclassable final class ConfusedParentClass {
>
> overridable final func quuz() {}
>
>   }
>
> The proposal doesn’t even address what that would do, the obvious answer is
> “compiler error,” but a better answer would be a language design that didn’t
> allow for this kind of ambiguity.
>
>
> Conflating access control and finality is confusing. The proposal actually
> even goes as far to argue that—“conflates” is a word I took from the
> proposal—but it’s solution *is* a conflation in of its right, because the
> only way to explain the results is in terms of both:
>
> classes, methods, properties, and subscripts with access control of
> `internal`, `file private`, and `private` are overridable by code that can
> access them, to prevent this add the `final` keyword.
> classes with access control of `public` are not overridable by code that can
> access them, to allow this replace the `public` keyword with the
> `subclassable` keyword.
> methods, properties, and subscripts with access control of `public` are not
> overridable by code that can access them, to allow this replace the `public`
> keyword with the `overridable` keyword.
>
>
> Not only is this complicated, and confusing, it isn’t even consistent: to
> deny overriding or subclassing you add the same keyword; but to allow
> overriding or subclassing you replace one keyword with two different ones,
> depending on which you’re doing.
>
>
> I agree that the alternative of flipping the default, and replacing `final`
> with `nonfinal` is also undesirable. One of the nicer features of the Swift
> language design is that the language is easiest for app developers working
> within a single module, where it can be assumed that “everyone is an adult.”
> Breaking this to support the less common case of Public API Designers would
> be a step backwards; their case is important, but it shouldn’t come at a
> penalty.
>
> Scott
>
> ___
> 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] Dropping Comparable requirement for indices

[Nate Cook via swift-evolution]

> On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> I've already raised the question here of whether we should weaken the
> requirement that Collection.Index be Comparable to merely being
> Equatable.  
> 
> Part of the motivation was to support data structures that otherwise
> would be expensive or impossible to implement.  For example, with
> Comparable indices, you can't build a linked list that supports
> restructuring (e.g. insert, delete, splice) in O(1) without invalidating
> indices... not even an unsafe linked list with reference semantics.
> [While I don't think linked lists are terribly good data structures for
> most things, they are still useful in teaching, and it bothered me that
> we were ruling them out.]  Even if you take away the index invalidation
> restriction, you have to store a counter in the index, which is an awkward 
> inefficiency.
> Supporting Comparable indices for a tree data structure requires
> encoding the path from the root to the node.  It's only one or two words
> in practice, but it's another awkward inefficiency.

So far in Swift 3 I've enjoyed the Comparable requirement on indices—it's much 
easier to perform bounds checks in collection algorithms as a result. However, 
I haven't tried implementing linked-lists or other non-linear collections since 
the Comparable requirement was added. I can see that requirement being a 
significant burden, particularly in a structure like a self-balancing tree, 
where managing index comparability could grow quite cumbersome.

> Over the weekend, I tried lifting the restriction to see what kind of
> effect it would have on the standard library.
> https://github.com/apple/swift/pull/3325
> 
> Although I *had* been leaning strongly toward making this change, having
> looked at the effects, I am now more ambivalent:
> 
> * A Range, where T is not Comparable, could be constructed with any
>  pair of Equatable T instances.  We'd only detect that the Range may be
>  invalid when T happened to also be Comparable.  However, the fact that
>  you are creating a Range already sort of implies an underlying
>  ordering.

This was exactly how Ranges worked from Swift's public launch up until the 
collections-move-indices changes landed, so it doesn't seem like a major 
problem to bring this behavior back. If we can promise better/faster bounds 
checking for Comparable indices, hopefully most collection authors would opt 
into that whenever possible.

> * A Collection with non-Comparable indices still imposes an ordering
>  upon the indices.
> 
> * In a Collection with Comparable indices, the ordering implied by <
>  needs to match the ordering of indices in the collection.  Otherwise,
>  there would be no way to form Ranges (for use in slicing, for example)
>  without causing a trap.  This is *weird*!  There's little precedent
>  for imposing stronger semantic requirements on an associated type if
>  it conforms to a particular protocol (Comparable in this case), except
>  where the requirement is part of the protocol.

This sounds like an argument *for* removing the Comparable requirement. Is the 
issue that it's difficult to guarantee that the < ordering matches the 
collection, or is the issue that even if you drop the Comparable requirement, 
there's an implicit comparability anyway?

> Also, Dmitri reminded me that even with a Comparable requirement on
> indices, there is still no problem converting an equatable iteration
> state into an index; you just need to augment it with an integer
> counter.  So it's still trivial to create a Collection from nearly
> everything that is today a multipass Sequence.  It does make indexing
> slightly more expensive, but it's likely we'd optimize that overhead
> away in many critical situations.
> 
> Anyway, the thoughts of the community on this topic would be interesting
> to us.  We need to make a decision about this very soon.

I don't know that I've helped at all, but those are my thoughts. Thanks!
Nate

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

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

[David Rönnqvist via swift-evolution]

>* What is your evaluation of the proposal?

+1. These look like good improvements to me. (I'm also happy that the 
map/filter/reduce naming was left out of this proposal)

One thing I was wonder about was the capitalization of UTF8 in the first 
example. Shouldn't that be s.withUTF8Buffer(processBytes)instead of 
s.withUtf8Buffer(processBytes) or am I confusing Swift's conventions with 
Cocoa's?

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

Yes. Inconsistency at this point in Swifts evolution should be dealt with.

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

Yes. These proposed labels help the call site read better as a sentence.

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


Quick reading of the proposal. Followed some of the discussion.

- David

> On 6 Jul 2016, at 01:10, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0118: Closure Parameter Names and Labels" begins now and 
> runs through July 11. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant via swift-evolution]

-1

This proposal makes Swift a more confusing language.


Swift already has a mechanism for creating public subclassable classes and 
non-subclassable classes:

  public class SubclassableParentClass { }

  public final class NonSubclassableParentClass { }

This mechanism also applies to methods, properties, and subscripts:

  public func bar() {}

  public final func foo() {}

The proposal makes no effort to remove this existing syntax.

The very fact that this would be legitimate syntax as a result is a bad omen to 
me:

  subclassable final class ConfusedParentClass {

overridable final func quuz() {}

  }

The proposal doesn’t even address what that would do, the obvious answer is 
“compiler error,” but a better answer would be a language design that didn’t 
allow for this kind of ambiguity.


Conflating access control and finality is confusing. The proposal actually even 
goes as far to argue that—“conflates” is a word I took from the proposal—but 
it’s solution *is* a conflation in of its right, because the only way to 
explain the results is in terms of both:

classes, methods, properties, and subscripts with access control of `internal`, 
`file private`, and `private` are overridable by code that can access them, to 
prevent this add the `final` keyword.
classes with access control of `public` are not overridable by code that can 
access them, to allow this replace the `public` keyword with the `subclassable` 
keyword.
methods, properties, and subscripts with access control of `public` are not 
overridable by code that can access them, to allow this replace the `public` 
keyword with the `overridable` keyword.

Not only is this complicated, and confusing, it isn’t even consistent: to deny 
overriding or subclassing you add the same keyword; but to allow overriding or 
subclassing you replace one keyword with two different ones, depending on which 
you’re doing.


I agree that the alternative of flipping the default, and replacing `final` 
with `nonfinal` is also undesirable. One of the nicer features of the Swift 
language design is that the language is easiest for app developers working 
within a single module, where it can be assumed that “everyone is an adult.” 
Breaking this to support the less common case of Public API Designers would be 
a step backwards; their case is important, but it shouldn’t come at a penalty.

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

Re: [swift-evolution] [Discussion] Parentheses

[Jens Persson via swift-evolution]

I'll try to rephrase my initial post a bit, perhaps it will make my point
clearer:

Might it be that some of the confusion regarding the evolution
(design/redesign) of tuples, parameter lists, etc. stems from the fact that
they all use parentheses? Or put differently: Parentheses, being used for
so many different (and similar) things, is perhaps blurring the "real"
(possibly simpler) similarities and differences.

I'm not saying they should not all use parentheses in the final design, I'm
only saying that perhaps it is making it harder to think clearly about
these things (while designing  the language).

Let's say we carry out a thought-experiment in which we assume that argument
and parameter lists use eg ≪≫ and tuples use eg ⊂⊃, and normal parentheses
are _only_ used for grouping and controlling priority in eg mathematical
expressions, but not when creating tuples, parameter lists, pattern
matching and closure types.

Using this notation (which is just a thinking-tool, not meant as a final
syntax), and reimagining these things from scratch, we could for example
try and see what happens if we assume that these are three _different_
types:
Int
⊂Int ⊃
⊂⊂ Int ⊃⊃
and also, for example, that it is ok to have single element tuples with an
element label.
And:

((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated as
usual / as before.

⊂ String, Int ⊃ // Two element tuple type whose elements are a String and
an Int.

⊂ Int ⊃ // Single element Tuple type.

⊂⊂ Int ⊃⊃ // Single element Tuple type whose only element is another single
element tuple type whose only element is an Int.

≪ Int ≫ -> Int // Function type from Int to Int.

Perhaps the ≪≫ would prove to be unnecessary, so:

Int -> Int // Function type from Int to Int.
(Int -> Int)? // Optional function type from Int to Int.
Int -> Int? // Optional function type from Int to Int. (remember
parens are _only_ used for grouping this way)

⊂ Int, Int, Int ⊃ -> Int // Function type from a 3-Int-tuple to an Int.
⊂⊂ Int, Int, Int ⊃⊃ -> Int // Function type from a single element tuple
whose element is a 3-Int-tuple to an Int. (Yes, nobody would probably write
a function of such a type, but allowing it could perhaps make the rules a
lot simpler.)

... Well, I think you get the idea.

I'm wondering if there has been any attempts at such from-the-scratch
redesigns of all these parentheses-related-things in the language
(including eg pattern matching, associated values and more).

/Jens


On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 06.07.2016 20:51, Joe Groff wrote:
>
>>
>> On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:
>>>
 Please feel free to ignore this naive attempt to engage in this
 discussion.

 My understanding of the history of Swift's tuples, argument lists,
 pattern
 matching, associated values, etc. in two steps:

 1. Initial Idealism *:
 Simple powerful heavily reused general concept.

 2. Iterative pragmatism / reality *:
 Complicated (exceptions to) rules.

 (* Inevitably not taking everything in to account.)

 Has there been any recent attempts to outline a more or less complete
 redesign for these things, returning to step 1 so to speak, but taking
 into
 account what has now been learned?


 As a side note (and supposedly trivial to most but me):

 Parentheses (parenthesized expressions in the grammar?) are used for
 all of
 these parts of the language, and they probably should be, but perhaps
 the
 similarities and differences between the language constructs can be made
 clearer to see by pretending that argument and parameter lists are
 written
 with eg ≪≫ and tuples with eg ⊂⊃, etc.?

 For example, I think most people agree that we should be able to use
 "sloppy/forgiving" parenthetical grouping in code such as:
 ((1 + (2 * 3)) * (x + (-5))) - y
 This is fine and can be used to express meaning for the person
 reading/writing, even though it means that some of the parens can become
 superfluous to a machine interpretation.

 AFAICS this need not have anything to do with tuples and/or parameter
 lists, but the fact that Swift is treating eg:
 func foo(x: Int) { print(x) }
 as
 func foo(x: Int) { print(x) }
 and
 ((Int, Int))
 as
 (Int, Int)

>>>
>>> If SE-0110 will be accepted, ((Int, Int)) will mean "1 tuple with
>>> Int,Int fields" and (Int, Int) will mean only "list of two Ints in
>>> parameters"
>>>
>>
>> ((Int, Int)) would still be equivalent to (Int, Int). SE-0110 only
>> concerns parameter lists in function types.
>>
>
> Yes, I'm talking about parameter list in function. Perhaps I'm missing
> something... Quotation from proposal:
>
> 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Intention.

IMO, intention may lead to more secure systems (and libraries). By
having to explicitly final everything I have to choose with parts of
my class/library would be locked and have to worry and check if any
public thing could be used to exploit it or make the system work in a
way I did not intended to. Also, final will prevent anyone including
me from extending/overriding. Defaulting to final would require from
me to explicitly declare the open endpoints in my libraries, so I
could explicitly open only the ones that are really intended to be
used in that way by third-parties.

As an example, I'm working on a system which has an internal
representation of Files and Folders using a common superclass (lets
call it Entry). I would like for other developers to be able to create
new entry types (not only inheriting from File) but I do not wish for
them to extend from Folder or any of its subclasses (specialised
folders). By using final I can prevent others from extending my Folder
but I cannot extend it myself and thus need another mechanism for
achieving this behaviour without bloating the Folder class with all
its specialisations. This proposal would allow me to make my Folder
and its subclasses publicly available/usable but would prevent others
from subclassing and thus misusing them in ways I did not intend them
to. The same rationale applies to methods.

L

On 6 July 2016 at 16:09, Goffredo Marocchi  wrote:
> Leonardo, how is defaulting to final/sealed helping you write better 
> libraries than having a final keyword for what you need to close instead?
>
> Sent from my iPhone
>
> On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution 
>  wrote:
>
>>> The review of "SE-0117: Default classes to be non-subclassable publicly" 
>>> begins now and runs through July 11. The proposal is available here:
>>>
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>>>
>>>* What is your evaluation of the proposal?
>>
>> +1. Being able to control how a class from my libraries are going to
>> be used by third-parties could enable a better designed API with more
>> control of how it is intended to be used. I'm just not fond of using
>> the proposed keywords ('subclassable' and 'overridable') as they feel
>> more like protocol or attribute names; I'd be more inclined to use the
>> alternative 'public open' instead, or 'public(open)' as a second
>> option.
>>
>>>* Is the problem being addressed significant enough to warrant a 
>>> change to Swift?
>>
>> I'd say it is significant to every language.
>>
>>>* 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?
>>
>> C# uses the keyword 'virtual' to explicitly mark methods that can be
>> overriden (not considered in the alternatives but I'm not a big fan of
>> it).
>>
>>>* How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>
>> I've took (a small) part on the thread discussing this proposal but
>> followed it closely
>> ___
>> 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-0107: UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jul 5, 2016, at 10:09 AM, Magnus Ahltorp via swift-evolution 
>  wrote:
> 
>> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through 
>> July 4, 2016. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
> 
> I have not had time for a full review, but I have a question about the 
> proposal:
> 
> When glancing at the examples, they strike me as mostly being marshalling, 
> which in my opinion would be better served by a safe marshalling API followed 
> by unsafe handling of the resulting buffer, and vice versa for unmarshalling. 
> I think it is very important (in the long run) that code that doesn't 
> interact with C directly has safe ways of doing inherently safe operations, 
> and not take the unsafe route just because that is the only API available.
> 
> My question is, how does this API fit into the bigger picture of marshalling, 
> and what are the benefits of using this API instead of marshalling with safe 
> buffers?
> 
> I would consider "we don't have time, we have to do this for now" a perfectly 
> valid answer.
> 
> /Magnus


I think that's a good point.

The examples in the "Motivation" section are contrived to demonstrate safety 
holes as tersely as possible. The examples in "Expected use
cases" are prototypical use cases that I expect most uses to fall under.

I think APIs for marshalling should evolve toward higher abstraction and 
safety. For starters, they should probably use UnsafeBufferPointer more often 
than UnsafePointer. But those APIs need time to evolve. The important thing for 
this release is to settle on the source-breaking changes to UnsafePointer and 
establish clear, verifiable rules for safety at the lowest level of the API.

One of the conundrums of this proposal is that well designed APIs should not 
need to use UnsafeRawPointer, but it does need to exist as the sanctioned way 
to work around limitations of UnsafePointer. If UnsafePointer is the *only* way 
to directly access a memory buffer, then it's natural for users to assume that 
they can use it as a valid workaround for all the messy interoperability, 
marshalling, and low-level buffer access problem that they face in practice. 
The situation today is that the UnsafePointer API encourages that misuse, and 
we possibly miscompile the code without warning.

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi via swift-evolution]

Leonardo, how is defaulting to final/sealed helping you write better libraries 
than having a final keyword for what you need to close instead?

Sent from my iPhone

On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution 
 wrote:

>> The review of "SE-0117: Default classes to be non-subclassable publicly" 
>> begins now and runs through July 11. The proposal is available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>> 
>>* What is your evaluation of the proposal?
> 
> +1. Being able to control how a class from my libraries are going to
> be used by third-parties could enable a better designed API with more
> control of how it is intended to be used. I'm just not fond of using
> the proposed keywords ('subclassable' and 'overridable') as they feel
> more like protocol or attribute names; I'd be more inclined to use the
> alternative 'public open' instead, or 'public(open)' as a second
> option.
> 
>>* Is the problem being addressed significant enough to warrant a 
>> change to Swift?
> 
> I'd say it is significant to every language.
> 
>>* 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?
> 
> C# uses the keyword 'virtual' to explicitly mark methods that can be
> overriden (not considered in the alternatives but I'm not a big fan of
> it).
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I've took (a small) part on the thread discussing this proposal but
> followed it closely
> ___
> 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] Removing Variadic Parameters.

[Leonardo Pessoa via swift-evolution]

-1_000_000_000

I believe variadic parameters are useful in a range of situations and
I use them myself a lot. As you mentioned yourself, you never created
variadic functions and you are allowed to continue working like that
for as long as it suits you so. It is a choice and you and other
developers are allowed to decide when and where to use it. As for
trailing closures, just as Saagar mentioned, your variadic parameter
does not have to be the last one, as it has to in C, and thus they do
not compete. Give it a try.

L

On 6 July 2016 at 15:49, Saagar Jha via swift-evolution
 wrote:
>
>
> On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution
>  wrote:
>>
>> It's a late answer… but I wanted to be a good citizen and checked if the
>> topic has been discussed before; so, it seems that is not the case ;-)
>>
>> In short, I agree:
>> Variadic parameters are somewhat cool, and I think I was exited when I've
>> seen them in C the first time… but I afair, I never created a variadic
>> function in production code, and I think I just used them for the first time
>> in Swift (I checked wether print is variadic…)
>> As of today, string interpolation has several advantages over old-style
>> string-formatting, and I can't remember any other method in one of the
>> established libraries that uses this feature:
>> Explicitly creating an array is just two additional characters, which
>> doesn't matter in a long list (which imho shouldn't be crammed into the
>> function call anyways), and when there are only a few parameters, you can
>> mimic variadics with Optionals defaulted to nil — and who knows what the
>> long-awaited hygienic macros might do to the importance of variadic
>> parameters.
>>
>> Additionally, variadic parameters compete with trailing closures, which
>> for me would always win the struggle for the last parameter ;-)
>
>
> Actually, you don’t have to make a variadic parameter last…print doesn’t.
>
>>
>>
>> As I said, I can't remember a single use case in Swift — and I already
>> utilized quite a lot of the "strange" techniques (currying, tuple splat,
>> complicated combinations of generics & protocols…).
>> So for me, the answer to the question "would I add this feature to Swift
>> if it wasn't there?" is a clear no…
>>
>> Tino
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> -Saagar Jha
>
> ___
> 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] Separating the finite-vs-infinite distinction from single-vs-multi-pass

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Anton Zhilin  wrote:

> 1. Do nothing with finiteness, because huge sequences are mostly like
> infinite ones, plus because infinite loops are useful
> 2. Allow collections to be infinite
> 3. Do not add new fields to collections, because infinite loops are
> useful

No argument so far, but...

> 4, Do not separate protocols
> Current model of IteratorProtocol + Sequence is a very simple and clean way
> to define one's own iterables. Let's not break it.

It's already broken.  When you call non-mutating methods such as map,
filter, or reduce on a Sequence, the sequence can be modified.  That
provblem was outlined very nicely by David Waite in
http://thread.gmane.org/gmane.comp.lang.swift.evolution/21295/focus=21872:

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

> Now to single-pass-ness.
> I would suggest the following model:
> 1. Iterable protocol is base of everything that can be used in for loop.
> Contains all single-pass-able operations.
> 2. IteratorProtocol is what Iterable returns. IteratorProtocol conforms to
> Iterable, returns itself. Single-pass sequences should conform to
> IteratorProtocol.
> 3. Sequence protocol conforms to Iterable. Sequences are multi-pass.

That solves no problems AFAICT and introduces a new protocol.  What's
the point?

> Also, we should leave both Sequence and Collection trees, because
> correctly conforming to Collection is a hard work, and correctly
> conforming to Sequence must be easy as pie.

That goal should not take precedence over logical coherence and
simplicity of the standard library.

Also, conforming to collection isn't really hard.

Finally, as mentioned earlier we could easily supply a protocol that
makes it no harder than conforming to IteratorProtocol is.  You don't
even need to make your iteration state equatable because we can compare
counters stored in the indices.  I'll post a gist illustrating this
today.

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

Re: [swift-evolution] Removing Variadic Parameters.

[Saagar Jha via swift-evolution]

On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> It's a late answer… but I wanted to be a good citizen and checked if the
> topic has been discussed before; so, it seems that is not the case ;-)
>
> In short, I agree:
> Variadic parameters are somewhat cool, and I think I was exited when I've
> seen them in C the first time… but I afair, I never created a variadic
> function in production code, and I think I just used them for the first
> time in Swift (I checked wether print is variadic…)
> As of today, string interpolation has several advantages over old-style
> string-formatting, and I can't remember any other method in one of the
> established libraries that uses this feature:
> Explicitly creating an array is just two additional characters, which
> doesn't matter in a long list (which imho shouldn't be crammed into the
> function call anyways), and when there are only a few parameters, you can
> mimic variadics with Optionals defaulted to nil — and who knows what the
> long-awaited hygienic macros might do to the importance of variadic
> parameters.
>
> Additionally, variadic parameters compete with trailing closures, which
> for me would always win the struggle for the last parameter ;-)
>

Actually, you don’t have to make a variadic parameter last…print doesn’t.


>
> As I said, I can't remember a single use case in Swift — and I already
> utilized quite a lot of the "strange" techniques (currying, tuple splat,
> complicated combinations of generics & protocols…).
> So for me, the answer to the question "would I add this feature to Swift
> if it wasn't there?" is a clear no…
>
> Tino
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Dmitri Gribenko via swift-evolution]

On Wed, Jul 6, 2016 at 11:30 AM, Harlan Haskins 
wrote:

> I’ve also seen unsafeAddressOf(_:) used when interfacing with C function
> pointers when the lifetime of an object is guaranteed. Many C APIs vend an
> API like:
>
> void perform_action(void (*callback)(void *data), void *initial_data);
>
> For which it is expected to use unsafeAddressOf on a class instance, like:
>
> perform_action({ data in
>   let _self = unsafeBitCast(data, to: MyClass.self)
>   _self.foo()
> }, data: unsafeAddressOf(self))
>
> It’s unsafe and error-prone, sure, but that’s why we have `unsafe` in the
> name  — I’ve had to use this to interface with libclang.
>

Hi Harlan,

For this case, Unmanaged is the recommended API.

Dmitri

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

Re: [swift-evolution] Removing Variadic Parameters.

[Tino Heth via swift-evolution]

It's a late answer… but I wanted to be a good citizen and checked if the topic 
has been discussed before; so, it seems that is not the case ;-)

In short, I agree:
Variadic parameters are somewhat cool, and I think I was exited when I've seen 
them in C the first time… but I afair, I never created a variadic function in 
production code, and I think I just used them for the first time in Swift (I 
checked wether print is variadic…)
As of today, string interpolation has several advantages over old-style 
string-formatting, and I can't remember any other method in one of the 
established libraries that uses this feature:
Explicitly creating an array is just two additional characters, which doesn't 
matter in a long list (which imho shouldn't be crammed into the function call 
anyways), and when there are only a few parameters, you can mimic variadics 
with Optionals defaulted to nil — and who knows what the long-awaited hygienic 
macros might do to the importance of variadic parameters.

Additionally, variadic parameters compete with trailing closures, which for me 
would always win the struggle for the last parameter ;-)

As I said, I can't remember a single use case in Swift — and I already utilized 
quite a lot of the "strange" techniques (currying, tuple splat, complicated 
combinations of generics & protocols…).
So for me, the answer to the question "would I add this feature to Swift if it 
wasn't there?" is a clear no…

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

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Saagar Jha via swift-evolution]

Most source breaking changes will be made in Swift 3. From now on code
should be mostly backwards compatible.

On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi there
>
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am  not
> very happy by having to change
> program source all the time:
>
> Therefore after Swift 3.0 is released I’d recommend kindly:
>
>
> Freeze Swift For Some Time!
> Do Not Change AnyThing For At Least 2 Years.
> (Yes you’ve read that correctly: two years.)
>
> Still there? OK, read on:
>
> In the mean time, you’ll have the great opportunity
> to fine-tune compiler and run time systems, to eliminate
> the few bugs there and make it blazingly fast!
>
> In two (or more) years,  there are enough Real Users (programmers)
> that by then will have enough practical experience with Swift, which
> might play a more solid role in improving Swift, and of course,
> are extremely happy with Swift, and that it is not changed
> all the time, So that they can concentrate on writing cool,
> reliable and decent programs, instead of revising it all
> the time!
>
> After such time, and much more intensive and practical usage,
> it becomes clear, what is good in Swift and what is not.
> What happens now, for instance, is that some base their “statistics” of
> which
> language elements etc. are frequently used or not, merely upon scanning
> a codebase of the relatively few (compared with e.g. ObjC, Java or C#)
> programmers
> that use Swift now
>
> Imho, Swift has not yet been in use long enough. It needs a prolonged time
> because now, most users have relatively little experience using Swift,
> thus the way they program now is not really representative with what one
> really can do
> with this powerful language, compared to experienced (years, not months)
> programmers in other languages.
> Still a lot has to be discovered, has to settle and form good mental
> pictures in
> programmer’s minds. It is all going a bit too fast, I think.
>
>
> Please (if you did’t already) realize that already many source
> code all over the world is written in Swift therefore it is very, very
> important that backwards compatibility should be preserved as much
> as possible. because  backwards-breaking-changes are a disaster
> to companies/individuals that have already hundreds or thousands
> of programs written in Swift.
>
> For comparison, until recently I did also programming projects on IBM
> mainframes for banks, insurance companies etc. The systems they use
> consists
> (per company) of literally thousands of Cobol and/or PL/1 programs written
> in all the years from ca 1970 until now. Still, one can take a program
> written
> in 1970 which compiles and runs flawlessly without any modification!
> All is backward compatible. If you would break backward
> compatibility in this domain you would probably be kicked of the planet..
>
>
> But even if we remain in macOS or iOS development, a huge amount of source
> code has been written in Objective C. Everyone would scream hell if you
> took
> out or change language elements..
> So please don’t. (it’s unnecessary)
>
>
> When Swift arrived, to me, it had already everything I need, not really
> missing anything.
> Of course, a programming language -like all things in life- is never
> perfect.
>
> To me it was also perfectly OK that Swift wasn’t open source, because
> those that
> have made Swift did a very good job. So one could even start thinking, why
> open source Swift? Why not leave it to Apple?
> But I guess I won’t make many friends asking this..
> And I also realize that many good ideas comes from open source.
>
>
> To me, Swift 2.2 and also 3.0  is fine.
> so, after that:
> you don’t have to change a thing.
> it works and has everything I need
> and is fast and stable.
> stop removing things.
> thanks.
>
>
> Kind Regards from beautiful Speyer.de in Germany
>
> TedvG
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Harlan Haskins via swift-evolution]

I’ve also seen unsafeAddressOf(_:) used when interfacing with C function 
pointers when the lifetime of an object is guaranteed. Many C APIs vend an API 
like:

void perform_action(void (*callback)(void *data), void *initial_data);

For which it is expected to use unsafeAddressOf on a class instance, like:

perform_action({ data in
  let _self = unsafeBitCast(data, to: MyClass.self)
  _self.foo()
}, data: unsafeAddressOf(self))

It’s unsafe and error-prone, sure, but that’s why we have `unsafe` in the name 
 — I’ve had to use this to interface with libclang.

(For an existing example of this, see SwiftGtk: 
https://github.com/TomasLinhart/SwiftGtk/blob/master/Sources/Application.swift 
)

— Harlan

> On Jul 6, 2016, at 11:01 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution 
> > wrote:
> 
> > Remove unsafeAddressOf. We are not aware of any real usecases for it. If 
> > there are any, it should be renamed to unsafeAddress(of:) to follow the 
> > guidelines.
> Obvious, unless someone comes up with use cases during the review period.
> 
> 
> It's minor, but I use unsafeAddressOf regularly for writing `description` 
> methods:
> 
> var description: String {
> return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info 
> here... }"
> }
> 
> I guess this would be covered by some generalized solution for format 
> specifiers in string interpolations, but I gather that won't happen for quite 
> a while...
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

[Douglas Gregor via swift-evolution]

> On Jul 6, 2016, at 10:43 AM, Jordan Rose  wrote:
> 
>> 
>> On Jul 1, 2016, at 15:53, Russ Bishop > > wrote:
>> 
>> 
>>> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md
>>>  
>>> 
>>>  ]
>>> 
>>> I’m pretty concerned about completely removing this feature. Yes, it’s a 
>>> type-checker / decl-checker nightmare, but I think Paolo’s example in the 
>>> initial discussion showed how it’s being used effectively today. I’d much 
>>> rather have some kind of inference marker that maps one-to-one between an 
>>> associated type and a value requirement (method, initializer, property, or 
>>> subscript), also as brought up in the original discussion. 
>>> 
>>> protocol OptionA {
>>>   associatedtype Index
>>> 
>>>   @infers(Index)
>>>   var startIndex: Index { get }
>>> 
>>>   var endIndex: Index { get }
>>> }
>>> 
>>> protocol OptionB {
>>>   @inferredFrom(startIndex) // allows a full name here for overload 
>>> resolution
>>>   associatedtype Index
>>> 
>>>   var startIndex: Index { get }
>>>   var endIndex: Index { get }
>>> } 
>>> 
>>> protocol OptionC {
>>>   associatedtype Index in startIndex // sugar
>>> 
>>>   var startIndex: Index { get }
>>>   var endIndex: Index { get }
>>> }
>>> 
>>> OptionC is the prettiest, but OptionA is probably the most flexible 
>>> (consider overloading on associated types).
>>> 
>>> I know we want to lock down on things now, and I know we can do better in 
>>> the future, but I think inferring associated types is really quite common, 
>>> and I’m concerned about taking it out without giving people a good 
>>> alternative. This is just an impression, though.
>>> 
>>> Jordan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> I’m trying to fill a gap in my own knowledge here. How does explicitly 
>> stating that startIndex is the inference point for Index help? 
>> 
>> Is it because various extensions and default implementations can provide 
>> different concrete types for Index, so the type checker is trying to resolve 
>> the ambiguity? If that’s the case, specifying startIndex here restricts the 
>> defaults/extensions that need to be considered from all to just ones that 
>> implement startIndex? Is that good enough generally or does it just solve 
>> the standard library’s problems?
>> 
>> Would it be enough to have rules along these lines for a concrete type 
>> adopting a protocol with associated types?
>> 
>> 1. If the type’s main declaration (not defaults or extensions) contains a 
>> member satisfying a protocol requirement (where the requirement is specified 
>> in terms of an associated type) the associated type is locked to the type 
>> used in that member, so no global inference is necessary. If more than one 
>> such member is present all must use the same exact type.
>> 2. Otherwise if there exists only one default/extension satisfying the 
>> associated type, the type used in that default implementation is used.
>> 3. In all other cases the user must specify the associated types explicitly.
> 
> I don't remember exactly how the current rules work, but I think the compiler 
> looks at all the members that mention an associated type and tries to figure 
> out if they're all in sync. Reducing that to just looking at one value 
> requirement might be enough to satisfy Doug's concerns, even if it still has 
> to do overload resolution…or you could follow the spirit of your rule 2 and 
> say that any overloads force you to specify the element type explicitly.

The compiler currently looks at all of the requirements that mention any of the 
associated types, then matches each requirement up to all potential 
declarations that might satisfy the requirement (whether they come from the 
concrete type, its extensions, or some protocol extension doesn’t matter) to 
infer potential types for each associated type requirement. A potential 
solution to the problem assigns a type for each associated type requirement, 
which then needs to be checked as a whole (e.g., did the type we infer for 
SubSequence meet the Sequence requirement, and is its Element type the same as 
our Element type?). When there are multiple possible solutions, they’re ranked 
based on which declarations were used to satisfy a particular requirement—a 
declaration from the concrete type is usually better than one from a protocol 
extension, for example—so one solution can be chosen.

And, really, you should 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Michael Peternell via swift-evolution]

> Am 06.07.2016 um 01:11 schrieb Chris Lattner via swift-evolution 
> :
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

-1
I think it's a step backwards.
If we really think that Swift is meant as a language for beginners then this is 
certainly the wrong direction to go to. Having to use a special keyword to 
allow a class to be subclassed from outside the module looks like the compiler 
has to perform some extra effort to add this "subclassability feature".

It's not bad to allow sealing of classes. I don't see real value in it though. 
And `sealed` should not be the default. Either the class if final or not: for 
me that's a valuable distinction. "sealed vs. unsealed" is not.

The proposal is another try to prevent people from misusing the language. But 
misusing the language will always be possible and will always be easy. All 
these attempts will make the language just more complicated or harder to 
understand. I don't buy the performance argument either, i.e. that "sealed by 
default" will improve performance considerably for non-contrived use-cases. But 
I'm sure you will find that out a few months after the proposal is implemented 
:-/

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

No

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

No, I don't think so.
If you have a ParentClass and a SubClass, and the ParentClass is sealed while 
the SubClass is subclassable. What happens? No matter how this question is 
answered, I don't like the answer. (compile error => bad. || make it as the 
user wishes => bad; what do we gain by letting ParentClass remain sealed? || 
make ParentClass implicitly subclassable too => bad.)

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

No

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

Participated in early discussions which didn't convince me at all.

-Michael

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

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

Re: [swift-evolution] [Discussion] Parentheses

[Vladimir.S via swift-evolution]

On 06.07.2016 20:51, Joe Groff wrote:



On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution 
 wrote:

On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:

Please feel free to ignore this naive attempt to engage in this discussion.

My understanding of the history of Swift's tuples, argument lists, pattern
matching, associated values, etc. in two steps:

1. Initial Idealism *:
Simple powerful heavily reused general concept.

2. Iterative pragmatism / reality *:
Complicated (exceptions to) rules.

(* Inevitably not taking everything in to account.)

Has there been any recent attempts to outline a more or less complete
redesign for these things, returning to step 1 so to speak, but taking into
account what has now been learned?


As a side note (and supposedly trivial to most but me):

Parentheses (parenthesized expressions in the grammar?) are used for all of
these parts of the language, and they probably should be, but perhaps the
similarities and differences between the language constructs can be made
clearer to see by pretending that argument and parameter lists are written
with eg ≪≫ and tuples with eg ⊂⊃, etc.?

For example, I think most people agree that we should be able to use
"sloppy/forgiving" parenthetical grouping in code such as:
((1 + (2 * 3)) * (x + (-5))) - y
This is fine and can be used to express meaning for the person
reading/writing, even though it means that some of the parens can become
superfluous to a machine interpretation.

AFAICS this need not have anything to do with tuples and/or parameter
lists, but the fact that Swift is treating eg:
func foo(x: Int) { print(x) }
as
func foo(x: Int) { print(x) }
and
((Int, Int))
as
(Int, Int)


If SE-0110 will be accepted, ((Int, Int)) will mean "1 tuple with Int,Int fields" and 
(Int, Int) will mean only "list of two Ints in parameters"


((Int, Int)) would still be equivalent to (Int, Int). SE-0110 only concerns 
parameter lists in function types.


Yes, I'm talking about parameter list in function. Perhaps I'm missing 
something... Quotation from proposal:


><
To declare a function type with one tuple parameter containing n elements 
(where n > 1), the function type's argument list must be enclosed by double 
parentheses:


let a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 }
><

Oh... Or do you(and Jens) mean that this:
let x : (Int, Int) = (1,2)
will be the same as this:
let x : ((Int, Int)) = (1,2)
? and about
func foo(_ x: ((Int, Int))) { print(x) }
vs
func foo(_ x: (Int, Int)) { print(x) }
?
In this case yes, sorry for misunderstanding, SE-0110 will not change this. 
I don't see any ambiguity here: foo will be called as

foo((1,2)) - clearly that tuple is sent as argument.



-Joe




seems to suggest that it somehow does.

Or maybe I have just forgotten the reasons for why there can be no such
thing as (a nested) single element tuple (type).

I also can't remember what the pros & cons of disallowing labeled single
element tuples were.

Happy to be corrected and pointed to relevant reading : )

/Jens



___
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] Dropping Comparable requirement for indices

[Dave Abrahams via swift-evolution]

on Wed Jul 06 2016, Brent Royal-Gordon  wrote:

>> On Jul 5, 2016, at 7:39 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> Anyway, the thoughts of the community on this topic would be interesting
>> to us.  We need to make a decision about this very soon.
>
> I've wanted the Index protocols to be Comparable since the Swift 1
> days. (Apple people, see rdar://17768142; non-Apple people, I was
> looking to measure distance and, under the old indexing model, the
> inability to determine which index came later was one of several
> impediments.)
>
> Going back to the beginning:
>
>> For example, with
>> Comparable indices, you can't build a linked list that supports
>> restructuring (e.g. insert, delete, splice) in O(1) without invalidating
>> indices... not even an unsafe linked list with reference semantics.
>> [While I don't think linked lists are terribly good data structures for
>> most things, they are still useful in teaching, and it bothered me that
>> we were ruling them out.]  Even if you take away the index invalidation
>> restriction, you have to store a counter in the index, which is an awkward 
>> inefficiency.
>
> You *can* have O(1) restructuring without index invalidation if you're
> willing to tolerate O(n) comparisons; you just walk forward from the
> left-hand side and return `true` if you encounter the right-hand side
> before reaching the end. 

Yeah, but O(1) is a basic requirement of Comparable.  I consider that to
be inviolable.

> I'm not certain, but I think there's a three-way tradeoff here: you
> can have any two of fast restructuring, fast comparisons, and
> always-valid indices.
>
> In general, though, `Collection` is not very good at modeling linked
> lists—for one thing, it can't model a value-typed linked list without
> enormous index invalidation issues. I can't quite bring myself to
> worry too much about linked-list handling here.

Yes, I'm not too worried about it either.  I'm more concerned about
trees, FWIW.

>> * A Range, where T is not Comparable, could be constructed with any
>>  pair of Equatable T instances.  We'd only detect that the Range may be
>>  invalid when T happened to also be Comparable.  However, the fact that
>>  you are creating a Range already sort of implies an underlying
>>  ordering.
>
> Such a Range can't actually test whether a given value is *in* the
> range. That basically just makes it a glorified typealias for
> `(lowerBound: Bound, upperBound: Bound)`. 

Yes.

> A Range without Comparable is a type without any semantics.

Practically speaking, yes.

>> * A Collection with non-Comparable indices still imposes an ordering
>>  upon the indices.
>
> And it also still needs to be able to *test* the ordering of
> indices. For instance, `distance(from:to:)` is a bit difficult to
> implement (at least in `BidirectionalCollection`) if you can't tell
> which index comes earlier in the collection.

Well, you can make it a precondition that the indices are in order.
That's what Swift 2 did (and what C++ does with its forward and
bidirectional iterators).  It is certainly nice that Swift 3 lifts that
restriction.

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

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

[Jacob Bandes-Storch via swift-evolution]

> * *Remove unsafeAddressOf*. "We are not aware of any real use cases for
> it. If there are any, it should be renamed to unsafeAddress(of:) to follow
> the guidelines." (https://bugs.swift.org/browse/SR-1957
> rdar://problem/18589289)
>
>
Oops, I just responded to this on another thread. Pasting:

It's minor, but I use unsafeAddressOf regularly for writing `description`
methods:

var description: String {
return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info
here... }"
}

I guess this would be covered by some generalized solution for format
specifiers in string interpolations, but I gather that won't happen for
quite a while...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

[Jacob Bandes-Storch via swift-evolution]

On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Remove unsafeAddressOf. We are not aware of any real usecases for it. If
> there are any, it should be renamed to unsafeAddress(of:) to follow the
> guidelines.
> Obvious, unless someone comes up with use cases during the review period.
>
>
It's minor, but I use unsafeAddressOf regularly for writing `description`
methods:

var description: String {
return "<\(self.dynamicType): \(unsafeAddressOf(self))>{ more info
here... }"
}

I guess this would be covered by some generalized solution for format
specifiers in string interpolations, but I gather that won't happen for
quite a while...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

[Roth Michaels via swift-evolution]

On Fri, Jul 01 2016 at 05:53:13 PM, Chris Lattner via swift-evolution 
 wrote:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0114-buffer-naming.md

>   * What is your evaluation of the proposal?
+1; Header is much more clear than Value in describing the purpose of
the property.  I did have to double check the docs to be sure Header
meant what I thought it did---which made me wonder if Metadata would be
a more instructional name, but I do like Header.

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

Yes, to me the Element array is the value of the buffer, so Value was a
bad name for this metadata property; Header is a much better name than Value.

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

Yes, increased clarity.

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

If have not dealt with this on a language level, but I have implemented
similar protocols at a user-framework level and would not use Value to
name this property.

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

Quick review, not much effort needed as it was simple to see the old
name was unclear and a poor description of the property.

-- 
Roth Michaels
r...@rothmichaels.us

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ted F.A. van Gaalen via swift-evolution]

>   * What is your evaluation of the proposal?


With all due respect, what is proposed here is imho completely unnecessary
and needlessly complicates Swift further. 

- in Object oriented development, subclassing should be encouraged, not limited.
 if one desires a class not to be subclassed simply add the modifier “final”

Using “final” (as in Java or C++) or “sealed” (as in C#) is imho the best way 
to do it.


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

No !  

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

This is a subjective domain. can’t answer that.  Anyway, it’s against the basic 
principles of OOD/OOP

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

N/A

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

I’ve read the proposal...


My opinion is based upon years of experience with OOP languages like Smalltalk, 
Java, Delphi Pascal, Objective C and C++ 

Kind Regards, now from speyer.de. 

Ted


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

[Jordan Rose via swift-evolution]

> On Jul 1, 2016, at 15:53, Russ Bishop  wrote:
> 
> 
>> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md
>>  
>> 
>>  ]
>> 
>> I’m pretty concerned about completely removing this feature. Yes, it’s a 
>> type-checker / decl-checker nightmare, but I think Paolo’s example in the 
>> initial discussion showed how it’s being used effectively today. I’d much 
>> rather have some kind of inference marker that maps one-to-one between an 
>> associated type and a value requirement (method, initializer, property, or 
>> subscript), also as brought up in the original discussion. 
>> 
>> protocol OptionA {
>>   associatedtype Index
>> 
>>   @infers(Index)
>>   var startIndex: Index { get }
>> 
>>   var endIndex: Index { get }
>> }
>> 
>> protocol OptionB {
>>   @inferredFrom(startIndex) // allows a full name here for overload 
>> resolution
>>   associatedtype Index
>> 
>>   var startIndex: Index { get }
>>   var endIndex: Index { get }
>> } 
>> 
>> protocol OptionC {
>>   associatedtype Index in startIndex // sugar
>> 
>>   var startIndex: Index { get }
>>   var endIndex: Index { get }
>> }
>> 
>> OptionC is the prettiest, but OptionA is probably the most flexible 
>> (consider overloading on associated types).
>> 
>> I know we want to lock down on things now, and I know we can do better in 
>> the future, but I think inferring associated types is really quite common, 
>> and I’m concerned about taking it out without giving people a good 
>> alternative. This is just an impression, though.
>> 
>> Jordan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m trying to fill a gap in my own knowledge here. How does explicitly 
> stating that startIndex is the inference point for Index help? 
> 
> Is it because various extensions and default implementations can provide 
> different concrete types for Index, so the type checker is trying to resolve 
> the ambiguity? If that’s the case, specifying startIndex here restricts the 
> defaults/extensions that need to be considered from all to just ones that 
> implement startIndex? Is that good enough generally or does it just solve the 
> standard library’s problems?
> 
> Would it be enough to have rules along these lines for a concrete type 
> adopting a protocol with associated types?
> 
> 1. If the type’s main declaration (not defaults or extensions) contains a 
> member satisfying a protocol requirement (where the requirement is specified 
> in terms of an associated type) the associated type is locked to the type 
> used in that member, so no global inference is necessary. If more than one 
> such member is present all must use the same exact type.
> 2. Otherwise if there exists only one default/extension satisfying the 
> associated type, the type used in that default implementation is used.
> 3. In all other cases the user must specify the associated types explicitly.

I don't remember exactly how the current rules work, but I think the compiler 
looks at all the members that mention an associated type and tries to figure 
out if they're all in sync. Reducing that to just looking at one value 
requirement might be enough to satisfy Doug's concerns, even if it still has to 
do overload resolution…or you could follow the spirit of your rule 2 and say 
that any overloads force you to specify the element type explicitly.

Rule 1, however, is the important one: "if more than one such member is present 
all must use the same exact type". I think that's already moving into the realm 
of spooky action and circularity issues that Doug's attempting to squash.

Jordan

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

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 6, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution 
>>  wrote:
>> 
>> * What is your evaluation of the proposal?
>> 
>> -1 as is. I do not want to be constrained by authors of libraries or
>> frameworks into interacting with a system in only the ways they forsee.
>> By making the default be non-subclassable, if a designer does not put
>> thought into all the ways a class can be used then I as a consumer of
>> the library am penalized.
> 
> Out of curiosity, what is your feeling about “internal” as the default level 
> of access control?  It seems that following your concern to its logical 
> conclusion would lead to a design where all members of a public class would 
> be forced to be public.  After all, the author of a library or framework may 
> not forsee the need to interact with a member that they did not explicitly 
> mark public

Can't really help for feel like it is training wheels all around... or padlocks 
on every kitchen cupboards. What if this had been the philosophy from swift 
0.1, what would the ecosystem look like today? (genuine question to which I do 
not have the answer)

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

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

[Douglas Gregor via swift-evolution]

> On Jul 5, 2016, at 10:35 PM, Ben Rimmington  wrote:
> 
> 
>> On 5 Jul 2016, at 21:41, Douglas Gregor > > wrote:
>> 
>>> The following comment is incorrect, AFAIK. The `helpAnchor` is the name 
>>> attribute of a HTML anchor element.
>>> 
>>> /// A localized message providing "help" text if the user requests help.
>>> var helpAnchor: String? { get }
>> 
>> Apple’s documentation says:
>> 
>> NSHelpAnchorErrorKey
>> The corresponding value is an NSString containing the localized help 
>> corresponding to the help button. See helpAnchor 
>> 
>>  for more information.
>> 
> 
> A `helpAnchor` in AppKit is the name of an HTML anchor element:
> 
> AppKit > NSPrintPanel > helpAnchor
>  >
> 
> AppKit > NSHelpManager > openHelpAnchor(_:inBook:)
>   
> >
> 
> Apple Help Programming Guide > Authoring Apple Help > Indexing Your Help Book 
> > Setting Anchors
>   
> >

The relevant “helpAnchor” is from the NSError reference documentation:


https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSError_Class/#//apple_ref/occ/instp/NSError/helpAnchor
 


which says:

A string to display in response to an alert panel help anchor button being 
pressed. (read-only)

Declaration
SWIFT
var helpAnchor: String 
?
 { get }
OBJECTIVE-C
@property(readonly, copy) NSString  
*helpAnchor
Discussion
The object in the user info dictionary for the key NSHelpAnchorErrorKey 
.
 If the user info dictionary doesn’t contain a value for NSHelpAnchorErrorKey 
,
 this property is nil.

If this property is non-nil for an error being presented by alertWithError: 
,
 the alert panel will include a help anchor button that can display this string.

Availability
Available in OS X v10.6 and later.

- Doug

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 5, 2016, at 9:11 PM, Kevin Lundberg  wrote:
> 
> I hadn't considered @testable, and it may be one way to mitigate the
> trouble this could cause in tests, so thank you both for bringing it up
> as the proposal should definitely account for it. I'm curious though how
> this would solve the case of trying to subclass a module's class in a
> test where you don't have the source? If you don't have control over the
> source, you can't rebuild it to enable testability, and it might even be
> desirable for someone to refuse to distribute a binary with testability
> enabled if doing so might reveal proprietary information or lead to a
> possible security problem with their library.

Our testing design is only intended to allow first-party tests to break the
normal access restrictions.  It seems to me that other tests should be
treating their external dependencies as black boxes and use their normal API.

John.

> 
> 
> On 7/5/2016 9:53 PM, John McCall via swift-evolution wrote:
>>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
* What is your evaluation of the proposal?
>>> I think it's ultimately a good idea. Being noncommittal about 
>>> subclassability/overridability—and thus forbidding it in public scope, but 
>>> not making any promises about what the module does internally—is the 
>>> alternative that preserves the most freedom for the module, and therefore 
>>> the most appropriate default.
>>> 
>>> However, I don't like the `subclassable` and `overridable` keywords. They 
>>> read like opposites of `final` with no implications for access level; I 
>>> could easily imagine somebody marking an internal class `subclassable` 
>>> assuming that it merely means it can be subclassed internally, and being 
>>> very surprised (or even not noticing!) that the class has been made public. 
>>> They're also long and cumbersome; that might be seen as a positive, but I 
>>> think it will increase the inevitable backlash against this change.
>>> 
>>> I prefer the keyword `open`, which sounds like it could be a statement 
>>> about the item's accessibility—and even sounds like it ought to be "more 
>>> public than public"—and is short enough that it ought to be difficult to 
>>> grumble about the change. It also means that both classes and members use 
>>> the same keyword, and gives us a keyword that we can later use to "open" 
>>> other things in the language, such as allowing you to extend enums with new 
>>> cases.
>> Agreed; I also prefer "open" to having two different long keywords that 
>> don't (at least to my ear) imply "public".
>> 
>>> I think Kevin Lundberg is right to worry about testability, but I don't 
>>> think that has to prevent this change. Instead, we should permit 
>>> `@testable` imports to subclass/override things that are not publicly 
>>> subclassable/overridable, and thus a module built with "Enable Testability" 
>>> on can't actually assume there are no subclasses/overrides of `internal` 
>>> classes/members even if it doesn't see any. This will block optimizations 
>>> in debug builds, but not in release builds. The proposal should be edited 
>>> to explain this `@testable` behavior.
>> IIUC the basic design of @testable is to treat the tests for the testable 
>> thing as existing within its module, so I think this just falls out.  I 
>> agree that it should be spelled out in the proposal, though.
>> 
>> John.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 5, 2016, at 10:56 PM, Chris Lattner  wrote:
>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>>> 
>>> I think Kevin Lundberg is right to worry about testability, but I don't 
>>> think that has to prevent this change. Instead, we should permit 
>>> `@testable` imports to subclass/override things that are not publicly 
>>> subclassable/overridable, and thus a module built with "Enable Testability" 
>>> on can't actually assume there are no subclasses/overrides of `internal` 
>>> classes/members even if it doesn't see any. This will block optimizations 
>>> in debug builds, but not in release builds. The proposal should be edited 
>>> to explain this `@testable` behavior.
>> 
>> IIUC the basic design of @testable is to treat the tests for the testable 
>> thing as existing within its module, so I think this just falls out.  I 
>> agree that it should be spelled out in the proposal, though.
> 
> That makes sense to me.  Please explicitly add that to the proposal, thank 
> you!

Done.

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

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Saleem Abdulrasool via swift-evolution]

On Tuesday, July 5, 2016, Chris Lattner  wrote:

>
> On Jul 5, 2016, at 5:28 PM, Saleem Abdulrasool  > wrote:
>
> On Tuesday, July 5, 2016, Chris Lattner  > wrote:
>
>>
>> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Sorry to resurrect such an old thread! I understand getting this in Swift
>> 3.0 might not be realistic anymore, but this is still something I’d love to
>> see added to Swift. Could someone advise on whether it still makes sense to
>> spend time on this proposal? Or is this part of Swift too solidified to
>> change at this point?
>>
>> It is definitely beyond Swift 3.0, but I’d love to see this happen at
>> some point, we really need someone to drive the (surely to be contentious)
>> design process.
>>
>
> I'm probably going to regret this, but given that I had originally
> proposed this to Brian and would really like to see this happen, what does
> this entail?
>
>
>
> 1) get some consensus on list for an overall approach
> 2) formalize a proposal and submit a PR to swift-evolution
> 3) iterate
>
> #1 is the hardest I think.  I don’t think a truly minimal wrapper of the
> POSIX APIs is interesting, I think we should at least make a Swifty POSIX
> API, which is portable and low-abstraction overhead.  However, it should
> fix the mistakes of errno and “creat” among other things.
>

That sounds pretty reasonable.  Especially if we do this earlier, breaking
from expectations in terms of mapping for things like "creat" would be less
intrusive.

Not sure what you had in mind for errno.  It seems like if we have an SDK
overlay for posix, we could hide errno, handling it similar to NSError.
However, I think that violates the low overhead.


> -Chris
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution