Re: [swift-evolution] [pitch] Comparison Reform

[Joe Groff via swift-evolution]

> On Apr 17, 2017, at 9:40 PM, Chris Lattner  wrote:
> 
> 
>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> For example, I expect `XCTAssertEqual(_:_:)` to be 
>>> vended as part of XCTest, in order to make sure that 
>>> `XCTAssertEqual(resultOfComputation, Double.nan)` always fails.
>> 
>> Unit tests strike me as an example of where you really *don't* want level 1 
>> comparison semantics. If I'm testing the output of an FP operation, I want 
>> to be able to test that it produces nan when I expect it to, or that it 
>> produces the right zero.
> 
> I find it very concerning that == will have different results based on 
> concrete vs generic type parameters.  This can only lead to significant 
> confusion down the road.  I’m highly concerned about situations where taking 
> a concrete algorithm and generalizing it (with generics) will change its 
> behavior.

In this case, I think we're making == do exactly what you want it to do based 
on context. If you're working concretely with floats, then you get 
floating-point behavior like you'd expect. If you're working with generically 
Equatable/Comparable things, then you're expecting the abstract guarantees of 
interchangeability and total ordering that implies, and you don't want to have 
to think about the edge cases of weird types that violate those constraints. I 
also doubt that this will cause problems in practice.

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

Re: [swift-evolution] [pitch] Comparison Reform

[Chris Lattner via swift-evolution]

> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> For example, I expect `XCTAssertEqual(_:_:)` to be vended 
>> as part of XCTest, in order to make sure that 
>> `XCTAssertEqual(resultOfComputation, Double.nan)` always fails.
> 
> Unit tests strike me as an example of where you really *don't* want level 1 
> comparison semantics. If I'm testing the output of an FP operation, I want to 
> be able to test that it produces nan when I expect it to, or that it produces 
> the right zero.

I find it very concerning that == will have different results based on concrete 
vs generic type parameters.  This can only lead to significant confusion down 
the road.  I’m highly concerned about situations where taking a concrete 
algorithm and generalizing it (with generics) will change its behavior.

-Chris

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

[swift-evolution] [Review] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0172 "One-sided Ranges" begins now and runs through April 23, 
2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

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

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
Reply text
Other replies
 What 
goes into a review?

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

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

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

Thank you,

-Doug

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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[David Sweeris via swift-evolution]

> On Apr 17, 2017, at 18:53, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> At a meta-level, since mistakes like SE–0025 will be much more costly in the 
> source-stable future, we ought to consider adding a step to the Swift 
> Evolution process whereby accepted proposals are implemented in a beta 
> version of Swift, and a second review period can happen if new problems 
> become apparent in actual usage that were unforeseen during the initial 
> discussion. That way we are much more likely to catch emergent issues before 
> release.

I see the benefit, but I'd have to think about it more before claiming to have 
an informed opinion.

- Dave Sweeris

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

Re: [swift-evolution] And another access control idea

[Brent Royal-Gordon via swift-evolution]

> On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> I’ve been following the access control discussion a little and I had an idea 
> that I wanted to throw out here. I know it’s too late and the idea doesn’t 
> provide source compatibility, but it seemed worthwhile to post it anyway. My 
> apologies if something similar has already been proposed.
> 
> First of all, I propose to use a trailing colon ‘:’ to make it clear that 
> it’s an access control keyword. Secondly, the idea introduces new keywords 
> that clearly describe the scope of access:
> 
> scope:   (formerly private)
> file:(formerly fileprivate)
> module:  (formerly internal, default)
> extern:  (formerly public)
> extern(open):(formerly open)
> 
> Examples:
> extern: class SomePublicClass {// explicitly public class
> extern: var somePublicProperty = 0 // explicitly public class member
> var someInternalProperty = 0   // implicitly internal class member
> file: func someFilePrivateMethod() {}  // explicitly file-private class 
> member
> scope: func somePrivateMethod() {} // explicitly private class member
> }
> 
> extern(open): class SomeOpenClass {// explicitly open class
> extern(open): func someOpenMethod() {} // explicitly open class member
> }
> 
> Having the keyword describe the access scope actually fits the access control 
> model of Swift very well. The user doesn’t have to learn what public or 
> private means, but only needs to know the concept. Especially coming from 
> another programming language I think public and private are confusing and 
> breaking with it will signal very clearly that the Swift model is different.
> 
> The idea is source breaking, but it’s very easy to deprecate the current 
> syntax with a warning and automatically migrate, because:
> All keywords are redefined, so there can be no confusion with the current 
> syntax.
> Only redefines the syntax, not the semantics.
> 
> Funny thing, I thought of this last night and when I woke up this morning I 
> read Erica’s proposal that uses many of the same keywords, although in a 
> different way. Telepathy? Or maybe we’re just onto something here?
> 
> I know this will turn everything upside down, but I like the overall 
> consistency, so I just wanted to throw it into the group as the next idea to 
> fix access controls and see if anyone likes it.
> 
> Alternatives considered:
> ‘all’ instead of ‘extern’. This sounds to me as if it can always be accessed 
> from everywhere, which might not be what we want if we introduce submodules.

Approaches like this were evaluated and rejected even before we introduced 
strict source stability requirements. `extern(open)` undoes an important 
feature of the `public`/`open` design, which is that there's no syntactic 
penalty for opening a symbol. And the SE-0169 acceptance specifically stated 
there would be no more access control changes in Swift 4.

I don't think this is a viable suggestion.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Nevin Brackett-Rozinsky via swift-evolution]

I am glad that “private” will become usable again in Swift 4. This
eliminates most of the pain caused by “fileprivate”.

However, I do not understand why this solution was chosen over renaming the
keywords. The discussion of alternatives here does not mention it, and the
only explanation given after SE-0159 is that renaming would cause “churn”.
Yet that renaming would be completely automatable by a migrator with no
change to semantics, whereas SE-0169 will require developers to manually
investigate each occurrence of “private” to see if the new meaning is still
appropriate, and introduce helper types to hide implementation details
where it is not.

Furthermore, I remain concerned that the mere act and fact of defining
“private” specifically to hide implementation details from other types in
the file will lead developers to put unrelated types together in a single
file, because that appears to be the intended purpose of the keyword.

At a meta-level, since mistakes like SE–0025 will be much more costly in
the source-stable future, we ought to consider adding a step to the Swift
Evolution process whereby accepted proposals are implemented in a beta
version of Swift, and a second review period can happen if new problems
become apparent in actual usage that were unforeseen during the initial
discussion. That way we are much more likely to catch emergent issues
before release.

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

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Xiaodi Wu via swift-evolution]

Simple: you put the user code that needs the more accurate library in one
file and import only the more accurate library there, and you put the user
code that needs the more performant library in a separate file and import
only the more performant library there! Swift's devotion to file-based
organization presents endless avenues of flexibility!

What you write is an argument for designing a more expressive import and/or
disambiguation feature, not for disallowing public retroactive conformance.
A proposal to rip out entirely the ability to vend public APIs with
extensions is simply not going to fly. The core team has committed to a
small standard library and multiple independent core libraries like
Foundation. This can only work because Foundation can greatly expand the
API of standard library types through extensions.

Your proposal would undo that design decision and require folding
Foundation's functionality into the standard library, or rewriting the
entire Foundation overlay to encapsulate standard library types instead of
extending them. For example, NSString would have to be a separate type that
encapsulates String. Yet oodles of work have gone into making NSString
seamlessly bridge to String in the first place.
On Mon, Apr 17, 2017 at 20:05 Howard Lovatt  wrote:

> Comments in-line below
>
> -- Howard.
>
> On 17 Apr 2017, at 9:01 am, Xiaodi Wu  wrote:
>
> This continues to forbid use cases that are critical.
>
>
> I think "critical" is overstating the importance. Plenty of successful
> languages do not have extensions. Extensions have been discussed and
> rejected by successful languages. The .NET guidelines suggest considered
> cautious use. I have tried to encapsulate the best practice into a language
> feature.
>
>
> For instance, I am writing a library that vends additional conformances
> for Float and Double. Any numerics library would need to do the same.
>
>
> You need to consider this carefully because your numerics library might
> add a method sinh for example and the user of your library might be using
> other numerical libraries as well, one of these others might also provide
> sinh. Which is to be called in the user code by f.sinh? Suppose one library
> emphasises speed over accuracy and the other vice versa. You really want
> access to both versions in the user code. This is a situation I have come
> across a few times in numeric C, Java, and C++ with matrix libraries where
> code I have worked on has used multiple libraries in the same application
> for good reason.
>
> I think you would be better vending functions for things like sinh, rather
> than extending float with an additional function, and vending types for
> more complex things like matrices, rather than extending arrays with dot
> products for example. If you vend a type you can easily give access to the
> underlying type using composition rather than extension or inheritance,
> there is an example of this in the proposal just above the Justification
> section..
>
>
> Your design would eliminate all such libraries, which is a non-starter. I
> am not sure what defects you are trying to solve with this proposal.
>
> I am trying to make Swift more consistent, easier to learn, and to
> encourage third-party libraries.
>
>
> On Sun, Apr 16, 2017 at 17:51 Howard Lovatt 
> wrote:
>
>> @Brent,
>>
>> I have updated the proposal to address your concerns, in particular I
>> don't see that retrospectively adding methods and protocols has been
>> removed it has just had its ugly corners rounded. See revised proposal
>> below particularly the end of section "Retrospectively adding protocols
>> and methods" and new section "Justification".
>>
>> Hope this convinces you that the change is worthwhile.
>>
>> -- Howard.
>>
>> 
>>
>> # Proposal: Split extension usage up into implementing methods and adding
>> methods and protocols retrospectively
>>
>>
>> ## Revision history
>>
>> | Version | Date   | Comment   |
>>
>> |-|--|--|
>>
>> | Draft 1   | 11 April 2017 | Initial version |
>>
>> | Draft 2  | 13 April 2017 | Added support for post-hoc conformance to a
>> protocol - replaced static final extensions with final extensions |
>>
>> | Draft 3 | 17 April 2017 | Added justification section |
>>
>>
>> ## Introduction
>>
>>
>> Currently extension methods are confusing because they have different
>> dispatch rules for the same calling syntax. EG:
>>
>>
>> public protocol P {
>>
>> func mP() -> String
>>
>>  }
>>
>> extension P {
>>
>> func mP() -> String { return "P.mP" }
>>
>> func mE() -> String { return "P.mE" }
>>
>> }
>>
>> struct S: P {
>>
>> func mP() -> String { return "S.mP" }
>>
>> func mE() -> String { return "S.mE" }
>>
>> }
>>
>> let s = S()
>>
>> s.mP() // S.mP as expected
>>
>> s.mE() // S.mE as 

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Howard Lovatt via swift-evolution]

Comments in-line below

-- Howard.

On 17 Apr 2017, at 9:01 am, Xiaodi Wu  wrote:

This continues to forbid use cases that are critical.


I think "critical" is overstating the importance. Plenty of successful
languages do not have extensions. Extensions have been discussed and
rejected by successful languages. The .NET guidelines suggest considered
cautious use. I have tried to encapsulate the best practice into a language
feature.


For instance, I am writing a library that vends additional conformances for
Float and Double. Any numerics library would need to do the same.


You need to consider this carefully because your numerics library might add
a method sinh for example and the user of your library might be using other
numerical libraries as well, one of these others might also provide sinh.
Which is to be called in the user code by f.sinh? Suppose one library
emphasises speed over accuracy and the other vice versa. You really want
access to both versions in the user code. This is a situation I have come
across a few times in numeric C, Java, and C++ with matrix libraries where
code I have worked on has used multiple libraries in the same application
for good reason.

I think you would be better vending functions for things like sinh, rather
than extending float with an additional function, and vending types for
more complex things like matrices, rather than extending arrays with dot
products for example. If you vend a type you can easily give access to the
underlying type using composition rather than extension or inheritance,
there is an example of this in the proposal just above the Justification
section..


Your design would eliminate all such libraries, which is a non-starter. I
am not sure what defects you are trying to solve with this proposal.

I am trying to make Swift more consistent, easier to learn, and to
encourage third-party libraries.


On Sun, Apr 16, 2017 at 17:51 Howard Lovatt  wrote:

> @Brent,
>
> I have updated the proposal to address your concerns, in particular I
> don't see that retrospectively adding methods and protocols has been
> removed it has just had its ugly corners rounded. See revised proposal
> below particularly the end of section "Retrospectively adding protocols
> and methods" and new section "Justification".
>
> Hope this convinces you that the change is worthwhile.
>
> -- Howard.
>
> 
>
> # Proposal: Split extension usage up into implementing methods and adding
> methods and protocols retrospectively
>
>
> ## Revision history
>
> | Version | Date   | Comment   |
>
> |-|--|--|
>
> | Draft 1   | 11 April 2017 | Initial version |
>
> | Draft 2  | 13 April 2017 | Added support for post-hoc conformance to a
> protocol - replaced static final extensions with final extensions |
>
> | Draft 3 | 17 April 2017 | Added justification section |
>
>
> ## Introduction
>
>
> Currently extension methods are confusing because they have different
> dispatch rules for the same calling syntax. EG:
>
>
> public protocol P {
>
> func mP() -> String
>
>  }
>
> extension P {
>
> func mP() -> String { return "P.mP" }
>
> func mE() -> String { return "P.mE" }
>
> }
>
> struct S: P {
>
> func mP() -> String { return "S.mP" }
>
> func mE() -> String { return "S.mE" }
>
> }
>
> let s = S()
>
> s.mP() // S.mP as expected
>
> s.mE() // S.mE as expected
>
> let p: P = s // Note: s now typed as P
>
> p.mP() // S.mP as expected
>
> p.mE() // P.mE unexpected!
>
>
> Extension methods can also cause compatibility problems between modules,
> consider:
>
>
> In Module A
>
> extension Int: P {
>
> func m() -> String { print("A.m") }
>
> }
>
>
> In Module B
>
> extension Int: P {
>
> func m() -> String { print("B.m") }
>
> }
>
>
> In Module C
>
> import A
>
> import B // Should this be an error
>
> let i = 0
>
> i.m() // Should it return A.m or B.m?
>
>
> This proposal cures the above two problems by separating extension methods
> into two seperate use cases: implementations for methods and adding methods
> and protocols retrospectively.
>
>
> ## Implementing methods
>
>
> If the extension is in the same file as the protocol/struct/enum/class
> declaration then it implements the methods and is dispatched using a
> Vtable. EG:
>
>
> File P.swift
>
> protocol/struct/enum/class P {
>
> // func m() not declared in type since it is added by the
> extension, under this proposal it is an error to include a declaration in a
> type *and* in an extension
>
> }
>
> extension P {
>
> func m() { print("P.m") } // m is added to the
> protocol/struct/enum/class declaration
>
> }
>
>
> Same or other file
>
> struct S: P {
>
> override func m() { print("S.m") } // Note override required
> because m already has an 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

It seems Float.init(exactly: NSNumber) has not been updated to behave
similarly?

I would have to say, I would naively expect "exactly" to behave exactly as
it says, exactly. I don't think it should be a synonym for
Float(Double(exactly:)).
On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
swift-evolution@swift.org> wrote:

> I posted my branch and fixed up the Double case to account for your
> concerns (with a few inspired unit tests to validate)
>
> https://github.com/phausler/swift/tree/safe_nsnumber
>
> There is a builtin assumption here though: it does presume that the
> swift’s representation of Double and Float are IEEE compliant. However that
> is a fairly reasonable assumption in the tests.
>
> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
>
>
>
> On Apr 14, 2017, at 22:51, Martin R  wrote:
>
> Thank you for the response, but I have more questions. Will
>
> Float(exactly: NSNumber(value: Double.pi))
>
>
> This will succeed in that the value is representable without loosing
> mantissa
>
>
> fail because Float cannot represent the number Double.pi exactly? Or
>
> Double(exactly: NSDecimalNumber(string: "1.9”))
>
>
> Again it would be representable without losing mantissa but…
>
>
> because Double cannot represent the decimal fraction 1.9 exactly?
>
>
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope
> of this proposal (it is it’s own type and bridges to Decimal)
>
>
> I find it difficult to evaluate the proposal without a description of the
> intended behavior of the "exact" conversions which covers all possible
> combinations (integers, floating point values, booleans). At present, the
> behavior is described only for stored integer types.
>
>
> I can post the patch but the real machinery is in NSNumber itself. The
> primary test is that if the value can round trip as the expected type and
> evaluate to equal to a NSNumber it will.
>
> The conversion roughy is a cast to and from the stored type;
>
> extension Double {
> init?(exactly number: NSNumber) {
> let value = number.doubleValue
> guard NSNumber(value: value) == number else { return nil }
> self = value
> }
> }
>
> The effective result of this is a verification of the stored type being
> equal to the fetched value. But specifically this only traverses via tagged
> pointers (if the are present). It is worth noting that this is not the
> exact implementation but an approximation with public apis.
>
> Overall this is by far a better behavior than just permissively allowing
> all conversions (which is the current alternative of doing nothing…). As
> one of the responsible maintainers for NSNumber I would claim that a
> generally permissive cast as it is today is incorrect usage of NSNumber.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 23:23, Philippe Hausler  wrote:
>
>
> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apologies if I am overlooking something, but it seems to me that the
> proposal does not clearly define the behavior of the "exact" conversions
> between integer and floating point values. Does
>
> Int(exactly: NSNumber(value: 12.34))
>
>
> The exact value of a float or double constructed NSNumber will only happen
> for integral values: e.g. 1.0, -32.0 etc
>
>
> fail because Int cannot represent the number exactly? Or are floating
> point values truncated silently and the conversion to an integer fails only
> if it overflows? And the other way around: Does
>
> Double(exactly: NSNumber(value: Int64(901)))
>
> fail because Double cannot represent the number exactly?
>
>
> I believe this will fail because the Int64 value will exceed the mantissa
> representation of the Double from my current implementation.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apologies, if you are reading this in HTML the links appear to be pointing
> to the incorrect proposal.
>
> Here is the corrected link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
> On Apr 14, 2017, at 11:30 AM, Ben Cohen  wrote:
>
> Hello Swift community,
>
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now
> and runs through the Friday after next, April 14th. The proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
> 

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Riley Testut via swift-evolution]

Extremely happy to see this outcome. Thank you Core Team for dealing with the 
seemingly never-ending arguments about access control, hopefully the majority 
of that is behind us now :^)

> On Apr 17, 2017, at 5:25 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> 
> Hello Swift Community,
> 
> The review of SE-0169 "Improve Interaction Between `private` Declarations and 
> Extensions” ran from April 6...11, 2017. The proposal is accepted.
> 
> This topic has been highly controversial for a long time, both during Swift 
> 3’s development (when SE-0025 was introduced) and during Swift 4 (including 
> SE-0159 and other proposals). There is no solution that will make everyone 
> happy: maintaining the status quo makes “fileprivate” too common and 
> therefore not meaningful when it occurs in source; removing or diluting 
> scope-level access control (as in SE-0159 and this proposal) takes away a 
> tool that is in use by Swift developers; and adding more levels of access 
> control complicates the language.
> 
> The core team feels that this proposal makes private access align more 
> closely with the goals of the language:
> 
> It supports the notion that extensions are a code-organization tool: one 
> should be able to break up a type’s definition into several extensions to 
> improve the clarity of that code, without having to open up access or 
> otherwise view the members in different extensions as completely-distinct 
> entities. The core team expects future language evolution to reinforce the 
> notion that extensions are more of a code organization tool than distinct 
> entities, e.g., allowing stored properties to be introduced in an extension.
> It makes private more usable as the default sub-internal access level, which 
> supports progressive disclosure of the access control system and better 
> matches with programmer’s expectations about what private access means.
> It makes fileprivate more meaningful, because it is only needed for those 
> cases where one is reaching across types (or among types and globals) within 
> a file. It will also become more rare, which matches well with its longer, 
> descriptive name.
> 
> The proposal’s acceptance includes one modification: extensions of a given 
> type that reside in a single file that is different from the file that 
> defines the type itself will have access to the private members of all other 
> extensions in that file. For example:
> 
> // FileA.swift
> struct A {
>   private var aMember : Int 
> }
> 
> // FileB.swift
> extension A {
> private func foo() {
> bar()// ok, foo() does have access to bar()
> }
> }
> 
> extension A {
> private func bar() {
> aMember = 42  // not ok, private members may not be accessed outside 
> their file.
> }
> }
> 
> The proposal has already been updated to reflect this change, which better 
> reflects the notion that extensions are a code-organization tool.
> 
> The core team considers the access-control matter closed for Swift 4 and will 
> not be reviewing any further proposals in this area.
> 
>   - Doug
>   Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
 


Hello Swift Community,

The review of SE-0169 "Improve Interaction Between `private` Declarations and 
Extensions” ran from April 6...11, 2017. The proposal is accepted.

This topic has been highly controversial for a long time, both during Swift 3’s 
development (when SE-0025 

 was introduced) and during Swift 4 (including SE-0159 

 and other  proposals 
). There is no solution that 
will make everyone happy: maintaining the status quo makes “fileprivate” too 
common and therefore not meaningful when it occurs in source; removing or 
diluting scope-level access control (as in SE-0159 

 and this proposal) takes away a tool that is in use by Swift developers; and 
adding more levels of access control complicates the language.

The core team feels that this proposal makes private access align more closely 
with the goals of the language:

It supports the notion that extensions are a code-organization tool: one should 
be able to break up a type’s definition into several extensions to improve the 
clarity of that code, without having to open up access or otherwise view the 
members in different extensions as completely-distinct entities. The core team 
expects future language evolution to reinforce the notion that extensions are 
more of a code organization tool than distinct entities, e.g., allowing stored 
properties to be introduced in an extension.
It makes private more usable as the default sub-internal access level, which 
supports progressive disclosure of the access control system and better matches 
with programmer’s expectations about what private access means.
It makes fileprivate more meaningful, because it is only needed for those cases 
where one is reaching across types (or among types and globals) within a file. 
It will also become more rare, which matches well with its longer, descriptive 
name.

The proposal’s acceptance includes one modification: extensions of a given type 
that reside in a single file that is different from the file that defines the 
type itself will have access to the private members of all other extensions in 
that file. For example:

// FileA.swift
struct A {
  private var aMember : Int 
}

// FileB.swift
extension A {
private func foo() {
bar()// ok, foo() does have access to bar()
}
}

extension A {
private func bar() {
aMember = 42  // not ok, private members may not be accessed outside 
their file.
}
}

The proposal has already been updated to reflect this change, which better 
reflects the notion that extensions are a code-organization tool.

The core team considers the access-control matter closed for Swift 4 and will 
not be reviewing any further proposals in this area.

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

I posted my branch and fixed up the Double case to account for your concerns 
(with a few inspired unit tests to validate)

https://github.com/phausler/swift/tree/safe_nsnumber 


There is a builtin assumption here though: it does presume that the swift’s 
representation of Double and Float are IEEE compliant. However that is a fairly 
reasonable assumption in the tests.

> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
> 
> 
> 
>> On Apr 14, 2017, at 22:51, Martin R > > wrote:
>> 
>> Thank you for the response, but I have more questions. Will
>> 
>> Float(exactly: NSNumber(value: Double.pi))
> 
> This will succeed in that the value is representable without loosing mantissa
> 
>> 
>> fail because Float cannot represent the number Double.pi exactly? Or
>> 
>> Double(exactly: NSDecimalNumber(string: "1.9”))
> 
> Again it would be representable without losing mantissa but… 
> 
>> 
>> because Double cannot represent the decimal fraction 1.9 exactly?
> 
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
> this proposal (it is it’s own type and bridges to Decimal)
> 
>> 
>> I find it difficult to evaluate the proposal without a description of the 
>> intended behavior of the "exact" conversions which covers all possible 
>> combinations (integers, floating point values, booleans). At present, the 
>> behavior is described only for stored integer types.
> 
> I can post the patch but the real machinery is in NSNumber itself. The 
> primary test is that if the value can round trip as the expected type and 
> evaluate to equal to a NSNumber it will.
> 
> The conversion roughy is a cast to and from the stored type;
> 
> extension Double {
>   init?(exactly number: NSNumber) {
>   let value = number.doubleValue
>   guard NSNumber(value: value) == number else { return nil }
>   self = value
>   }
> }
> 
> The effective result of this is a verification of the stored type being equal 
> to the fetched value. But specifically this only traverses via tagged 
> pointers (if the are present). It is worth noting that this is not the exact 
> implementation but an approximation with public apis.
> 
> Overall this is by far a better behavior than just permissively allowing all 
> conversions (which is the current alternative of doing nothing…). As one of 
> the responsible maintainers for NSNumber I would claim that a generally 
> permissive cast as it is today is incorrect usage of NSNumber.
> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 23:23, Philippe Hausler >> > wrote:
>>> 
 
 On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
 > wrote:
 
 Apologies if I am overlooking something, but it seems to me that the 
 proposal does not clearly define the behavior of the "exact" conversions 
 between integer and floating point values. Does
 
 Int(exactly: NSNumber(value: 12.34))
>>> 
>>> The exact value of a float or double constructed NSNumber will only happen 
>>> for integral values: e.g. 1.0, -32.0 etc
>>> 
 
 fail because Int cannot represent the number exactly? Or are floating 
 point values truncated silently and the conversion to an integer fails 
 only if it overflows? And the other way around: Does
 
 Double(exactly: NSNumber(value: Int64(901)))
 
 fail because Double cannot represent the number exactly?
>>> 
>>> I believe this will fail because the Int64 value will exceed the mantissa 
>>> representation of the Double from my current implementation. 
>>> 
 
 Regards, Martin
 
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
> > wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be 
> pointing to the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>> On Apr 14, 2017, at 11:30 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
>> and runs through the Friday after next, April 14th. The proposal is 
>> available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> Reviews are an important part of the Swift evolution 

[swift-evolution] [Accepted] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
 


The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
Swift” ran April 5...9, 2017. The first review 

 established the main substance of the proposal, while the second review 
focused mostly on the more lightweight “\” syntax. The proposal is accepted 
with one clarification regarding the intersection between contextual keypaths 
(where the base type is left unspecified) and array types.

The core team felt that the leading “\” is our best option for introducing 
keypaths. It is lightweight, yet provides a visual “escape” to indicate that 
the evaluation of the entities being referenced is being delayed. As noted in 
the result of the first review 
,
 this is part of a longer-term plan to use the “\” for unapplied method 
references, bringing the two closely-related features into syntactic alignment 
over time and providing an opportunity to stage in the important but 
currently-source-breaking changes accepted in SE-0042 
.

Much discussion centered around potential ambiguities. Accessing a property of 
a key path, e.g., \Person.friends[0].firstName.someKeyPathProperty, requires 
one to parenthesize the key path as 
(\Person.friends[0].firstName).someKeyPathProperty,  which is a common way to 
disambiguate expressions in Swift (and most other programming languages) 
already. More concerning to the core team was the ambiguity between contextual 
keypaths starting with a subscript and keypaths rooted on an array type, e.g.,

\[a]?.foo // is [a]? a type rooting a keypath “.foo”
  // or is it a contextual keypath starting with a 
subscript [a]?

To resolve this ambiguity, *all* contextual keypaths will start with “\.”. The 
expression above will use the first interpretation (a type [a]? rooting a key 
path “.foo”), while the second interpretation would be written as:

\.[a]?.foo// a contextual key path starting with the subscript [a]

The core team felt that the result is more consistent: “\.” indicates a 
contextual keypath, while “\” without the “.” indicates a keypath with a 
specified root.

The authors will revise the proposal according. Thank you to everyone who 
participated in the reviews of this much-anticipated feature!

- Doug
Review Manager

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

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Michael Ilseman via swift-evolution]

My understanding is that there is no mechanism yet to guarantee stack 
allocation for anything.

> On Apr 17, 2017, at 3:29 PM, Karl Wagner  wrote:
> 
> 
>> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> This is the best approach that I’m aware of. It does bake in an ABI 
>> assumption that the tuple layout will be contiguous and strided/addressable. 
>> Monitor https://bugs.swift.org/browse/SR-3726 
>>  for changes here. Note that you can 
>> also a little more “pure” in a sense if you construct an UnsafeBufferPointer 
>> from your UnsafeRawPointer and operate on that. Currently, the compiler does 
>> not always elide the copy in the getter, see 
>> https://bugs.swift.org/browse/SR-4581 
>> 
> 
> Will the compiler ever optimise an UBP allocation on to the stack? For 
> example, I’ve written plenty of code such as:
> 
> let ptr = UnsafeRawBufferPointer.allocate(count: 128)
> defer { ptr.deallocate(count: 128) }
> 
> ...when interfacing with C APIs. Which is basically the definition of a stack 
> allocation. That would perhaps be the “swiftier” way to do it; to let the 
> compiler determine how to allocate the memory based on what it knows about 
> its expected lifetime.

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

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Karl Wagner via swift-evolution]

> On 18 Apr 2017, at 00:29, Karl Wagner  wrote:
> 
> 
>> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> This is the best approach that I’m aware of. It does bake in an ABI 
>> assumption that the tuple layout will be contiguous and strided/addressable. 
>> Monitor https://bugs.swift.org/browse/SR-3726 
>>  for changes here. Note that you can 
>> also a little more “pure” in a sense if you construct an UnsafeBufferPointer 
>> from your UnsafeRawPointer and operate on that. Currently, the compiler does 
>> not always elide the copy in the getter, see 
>> https://bugs.swift.org/browse/SR-4581 
>> 
> 
> Will the compiler ever optimise an UBP allocation on to the stack? For 
> example, I’ve written plenty of code such as:
> 
> let ptr = UnsafeRawBufferPointer.allocate(count: 128)
> defer { ptr.deallocate(count: 128) }
> 
> ...when interfacing with C APIs. Which is basically the definition of a stack 
> allocation. That would perhaps be the “swiftier” way to do it; to let the 
> compiler determine how to allocate the memory based on what it knows about 
> its expected lifetime.


I’ll answer that: no, it won’t.

echo "let ptr = UnsafeMutableRawPointer.allocate(bytes: 128, alignedTo: 1); 
defer { ptr.deallocate(bytes: 128, alignedTo: 1) }" | swiftc -O -emit-assembly -

.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 9
.globl  _main
.p2align4, 0x90
_main:
pushq   %rbp
movq%rsp, %rbp
movl$128, %edi
xorl%esi, %esi
callq   _swift_rt_swift_slowAlloc   ; a.k.a. ‘malloc'
movq%rax, __Tv4main3ptrSv(%rip)
movl$128, %esi
xorl%edx, %edx
movq%rax, %rdi
callq   _swift_rt_swift_slowDealloc ; a.k.a ‘free'
xorl%eax, %eax
popq%rbp
retq

Would be cool to do one day, though.

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

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Karl Wagner via swift-evolution]

> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution 
>  wrote:
> 
> This is the best approach that I’m aware of. It does bake in an ABI 
> assumption that the tuple layout will be contiguous and strided/addressable. 
> Monitor https://bugs.swift.org/browse/SR-3726 
>  for changes here. Note that you can 
> also a little more “pure” in a sense if you construct an UnsafeBufferPointer 
> from your UnsafeRawPointer and operate on that. Currently, the compiler does 
> not always elide the copy in the getter, see 
> https://bugs.swift.org/browse/SR-4581 
> 

Will the compiler ever optimise an UBP allocation on to the stack? For example, 
I’ve written plenty of code such as:

let ptr = UnsafeRawBufferPointer.allocate(count: 128)
defer { ptr.deallocate(count: 128) }

...when interfacing with C APIs. Which is basically the definition of a stack 
allocation. That would perhaps be the “swiftier” way to do it; to let the 
compiler determine how to allocate the memory based on what it knows about its 
expected lifetime.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0171: Reduce with inout

[Matthew Johnson via swift-evolution]

> On Apr 17, 2017, at 4:59 PM, Jaden Geller  wrote:
> 
>> 
>> On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Fri Apr 14 2017, Matthew Johnson >> > wrote:
>>> 
> On Apr 14, 2017, at 9:05 PM, David Sweeris  > wrote:
> 
> 
>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>>>  • What is your evaluation of the proposal?
>> 
>> +0.5 because this is a half solution.  I would also like to see a
>> variant which accepts an inout argument for the reduction to
>> accumulate into.
> 
> Out of curiosity, do you have any particular use case in mind, or do
> you just think that'd nicely "round out" the reduce functions (which
> would be fine with me).
 
 This would be useful in any use case that involves reducing data that
 isn’t all available at the same time for one reason or another
 (batches arrive periodically, data is processed in chunks to avoid
 loading everything into memory, etc).
 
 IMO the most fundamental variation of `reduce` Swift could offer is
 the one that takes and `inout` accumulator.  The others can easily be
 defined in terms of that.
>>> 
>>> It should work to do this:
>>> 
>>>  existingAccumulator = reduce(into: existingAccumulator) { ... }
>>> 
>>> If reduce is inlined, ARC is doing its job right, and the closure isn't
>>> throwing, it shouldn't even cost a copy of existingAccumulator.
>>> 
>>> If you have a heaviweight accumulator with value semantics and ARC
>>> isn't cutting it for you, you can do this ugly thing instead.
>>> 
>>>  extension Optional {
>>>mutating func release() -> Wrapped {
>>>  defer { self = nil }
>>>  return self!
>>>}
>>>  }
>>> 
>>>  var accumulator: AccumulatorType? = AccumulatorType()
>>>  accumulator = reduce(into: accumulator.release()) { ... }
>>> 
>>> but then you lose the accumulator if the closure throws.  So, I guess
>>> I'm agreeing with you that the version with the inout accumulator is
>>> more fundamental.
>> 
>> Even if this would work I don’t think it’s a great option.  Accepting an 
>> inout accumulator is a far more straightforward programming model with clear 
>> performance semantics that don’t require detailed implementation knowledge.
>> 
>>> 
>>> But that's not the only criterion.  Is it as useful and commonly
>>> convenient?  
>> 
>> I would say it is commonly useful.  When it is required it is as convenient 
>> as possible.  When an inout accumulator is not required it is admittedly 
>> somewhat less convenient.
>> 
>> Whether it is *as* useful and convenient as the proposed variation probably 
>> depends on the domain.  Each has their strength with the proposed version 
>> probably being a bit more frequently desired.
>> 
>>> If we were to have both versions, how would you name them?
>> 
>> This is a tough question.  The proposed `into:` label makes sense for both 
>> the inout accumulator and the proposed variation but I’ll assume overloading 
>> won’t be considered for the reasons stated in the proposal.  `intoCopyOf:` 
>> would make sense for the proposed copying variation but would penalize it 
>> with verbosity and doesn’t copy reference types despite implying that. 
> 
> It seems to me that it isn’t problematic to overload with an `inout` variant. 
> It is always clear to the compiler which to choose based on the presence or 
> lack of a `&` character.


That’s a good point.  Also worth noting is that the in-place mutating variation 
would probably return `Void`.  If users accidentally omit the `&` sigil the 
compiler will complain about an unused result because they would not be 
intending for any result to be available at all.  Maybe we can get away with 
overloading the `into:` label.

> 
>> The `mutating:` label described in the alternatives considered section of 
>> the proposal might might be the best option.  One downside would be if the 
>> difference between `into:` and `mutating:` isn't sufficiently clear.  Given 
>> that both the types *and* the labels distinct I think it’s probably ok.  The 
>> second potential source of confusion would be if using `mutating:` as a 
>> label might cause some confusion with mutating methods.  Again, a quick 
>> glance at the types reveals that the method is not mutating and the 
>> accumulator argument is taken as inout.
>> 
>> What is your thought on using the `into` for the proposed variation and 
>> `mutating` for the variation with an inout accumulator?
>> 
>>> 
>>> -- 
>>> -Dave
>>> 

Re: [swift-evolution] SE-0171: Reduce with inout

[Jaden Geller via swift-evolution]

> On Apr 17, 2017, at 2:37 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Fri Apr 14 2017, Matthew Johnson > > wrote:
>> 
 On Apr 14, 2017, at 9:05 PM, David Sweeris > wrote:
 
 
> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
>>  • What is your evaluation of the proposal?
> 
> +0.5 because this is a half solution.  I would also like to see a
> variant which accepts an inout argument for the reduction to
> accumulate into.
 
 Out of curiosity, do you have any particular use case in mind, or do
 you just think that'd nicely "round out" the reduce functions (which
 would be fine with me).
>>> 
>>> This would be useful in any use case that involves reducing data that
>>> isn’t all available at the same time for one reason or another
>>> (batches arrive periodically, data is processed in chunks to avoid
>>> loading everything into memory, etc).
>>> 
>>> IMO the most fundamental variation of `reduce` Swift could offer is
>>> the one that takes and `inout` accumulator.  The others can easily be
>>> defined in terms of that.
>> 
>> It should work to do this:
>> 
>>  existingAccumulator = reduce(into: existingAccumulator) { ... }
>> 
>> If reduce is inlined, ARC is doing its job right, and the closure isn't
>> throwing, it shouldn't even cost a copy of existingAccumulator.
>> 
>> If you have a heaviweight accumulator with value semantics and ARC
>> isn't cutting it for you, you can do this ugly thing instead.
>> 
>>  extension Optional {
>>mutating func release() -> Wrapped {
>>  defer { self = nil }
>>  return self!
>>}
>>  }
>> 
>>  var accumulator: AccumulatorType? = AccumulatorType()
>>  accumulator = reduce(into: accumulator.release()) { ... }
>> 
>> but then you lose the accumulator if the closure throws.  So, I guess
>> I'm agreeing with you that the version with the inout accumulator is
>> more fundamental.
> 
> Even if this would work I don’t think it’s a great option.  Accepting an 
> inout accumulator is a far more straightforward programming model with clear 
> performance semantics that don’t require detailed implementation knowledge.
> 
>> 
>> But that's not the only criterion.  Is it as useful and commonly
>> convenient?  
> 
> I would say it is commonly useful.  When it is required it is as convenient 
> as possible.  When an inout accumulator is not required it is admittedly 
> somewhat less convenient.
> 
> Whether it is *as* useful and convenient as the proposed variation probably 
> depends on the domain.  Each has their strength with the proposed version 
> probably being a bit more frequently desired.
> 
>> If we were to have both versions, how would you name them?
> 
> This is a tough question.  The proposed `into:` label makes sense for both 
> the inout accumulator and the proposed variation but I’ll assume overloading 
> won’t be considered for the reasons stated in the proposal.  `intoCopyOf:` 
> would make sense for the proposed copying variation but would penalize it 
> with verbosity and doesn’t copy reference types despite implying that. 

It seems to me that it isn’t problematic to overload with an `inout` variant. 
It is always clear to the compiler which to choose based on the presence or 
lack of a `&` character.

> The `mutating:` label described in the alternatives considered section of the 
> proposal might might be the best option.  One downside would be if the 
> difference between `into:` and `mutating:` isn't sufficiently clear.  Given 
> that both the types *and* the labels distinct I think it’s probably ok.  The 
> second potential source of confusion would be if using `mutating:` as a label 
> might cause some confusion with mutating methods.  Again, a quick glance at 
> the types reveals that the method is not mutating and the accumulator 
> argument is taken as inout.
> 
> What is your thought on using the `into` for the proposed variation and 
> `mutating` for the variation with an inout accumulator?
> 
>> 
>> -- 
>> -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

Cheers,
Jaden Geller

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Nevin Brackett-Rozinsky via swift-evolution]

On Mon, Apr 17, 2017 at 4:52 PM, Tino Heth <2...@gmx.de> wrote:

>
> the only way to hide one invariant from the other’s methods is to use
> helper types
>
> Could you elaborate here and give an example that uses such helper types?
>


Okay, let’s say we have a type Foo with a String property and an Int
property. The invariants we’ll preserve are that the String must begin with
“secret ” and the Int must be divisible by 3.

struct Foo {
private var secretString = SecretString()
private var divisibleBy3 = MultipleOfThree()

var x: Int {
get { return divisibleBy3.value }
set { divisibleBy3.update(newValue) }
}

var y: String {
get { return secretString.value }
set { secretString.update(newValue) }
}

// rest of the implementation
}

private struct MultipleOfThree {
private(set) var value: Int = 0
mutating func update(_ n: Int) { value = 3 * n }
}

private struct SecretString {
private(set) var value: String = "secret value"
mutating func update(_ s: String) { value = "secret " + s }
}

Now the only places that the invariants could possibly be broken are inside
the helper types themselves. Anything within the implementation of Foo can
call the “update” functions, but cannot directly alter the values inside
the helper types and so cannot violate the invariants. Thus, with this
pattern, to confirm that the invariants are preserved we need only look at
the helper types, which are short and self-contained.

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

>  That’s why open is a success IMHO
I always appreciate when personal opinion is marked — I just want to point out 
this could apply to two aspects here ("that's why" and "open is a success" ;-)

> I don’t think its worth arguing about renaming again. Yes, its technically a 
> better option,
There's rarely complete agreement about anything, but exceptions aside: Is 
there consensus about this?
If that's actually the case, I think we really should take a step back and 
question ourselves:
This would mean Swift discards a compromise which was afaics widely accepted in 
favour of something worse because… it is to much work and the "other languages" 
would laugh about our fickleness?
And would keeping status quo be so much worse than status quo with new names?
I'm not sure about the longevity of the Swift 4 model of access control 
(however it may look like), but afaik, we might have to live with it for a long 
time — and many future users of Swift (without any legacy-knowledge) as well. 

> but the Core Team will not consider it for the same reasons they rejected 
> SE-0159. I’m under the impression that SE-0169 is the only solution we have.


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

Re: [swift-evolution] SE-0171: Reduce with inout

[Matthew Johnson via swift-evolution]

> On Apr 16, 2017, at 12:47 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Apr 14 2017, Matthew Johnson  > wrote:
> 
>>> On Apr 14, 2017, at 9:05 PM, David Sweeris  wrote:
>>> 
>>> 
 On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution 
  wrote:
 
 
>  • What is your evaluation of the proposal?
 
 +0.5 because this is a half solution.  I would also like to see a
 variant which accepts an inout argument for the reduction to
 accumulate into.
>>> 
>>> Out of curiosity, do you have any particular use case in mind, or do
>>> you just think that'd nicely "round out" the reduce functions (which
>>> would be fine with me).
>> 
>> This would be useful in any use case that involves reducing data that
>> isn’t all available at the same time for one reason or another
>> (batches arrive periodically, data is processed in chunks to avoid
>> loading everything into memory, etc).
>> 
>> IMO the most fundamental variation of `reduce` Swift could offer is
>> the one that takes and `inout` accumulator.  The others can easily be
>> defined in terms of that.
> 
> It should work to do this:
> 
>  existingAccumulator = reduce(into: existingAccumulator) { ... }
> 
> If reduce is inlined, ARC is doing its job right, and the closure isn't
> throwing, it shouldn't even cost a copy of existingAccumulator.
> 
> If you have a heaviweight accumulator with value semantics and ARC
> isn't cutting it for you, you can do this ugly thing instead.
> 
>  extension Optional {
>mutating func release() -> Wrapped {
>  defer { self = nil }
>  return self!
>}
>  }
> 
>  var accumulator: AccumulatorType? = AccumulatorType()
>  accumulator = reduce(into: accumulator.release()) { ... }
> 
> but then you lose the accumulator if the closure throws.  So, I guess
> I'm agreeing with you that the version with the inout accumulator is
> more fundamental.

Even if this would work I don’t think it’s a great option.  Accepting an inout 
accumulator is a far more straightforward programming model with clear 
performance semantics that don’t require detailed implementation knowledge.

> 
> But that's not the only criterion.  Is it as useful and commonly
> convenient?  

I would say it is commonly useful.  When it is required it is as convenient as 
possible.  When an inout accumulator is not required it is admittedly somewhat 
less convenient.

Whether it is *as* useful and convenient as the proposed variation probably 
depends on the domain.  Each has their strength with the proposed version 
probably being a bit more frequently desired.

> If we were to have both versions, how would you name them?

This is a tough question.  The proposed `into:` label makes sense for both the 
inout accumulator and the proposed variation but I’ll assume overloading won’t 
be considered for the reasons stated in the proposal.  `intoCopyOf:` would make 
sense for the proposed copying variation but would penalize it with verbosity 
and doesn’t copy reference types despite implying that.  

The `mutating:` label described in the alternatives considered section of the 
proposal might might be the best option.  One downside would be if the 
difference between `into:` and `mutating:` isn't sufficiently clear.  Given 
that both the types *and* the labels distinct I think it’s probably ok.  The 
second potential source of confusion would be if using `mutating:` as a label 
might cause some confusion with mutating methods.  Again, a quick glance at the 
types reveals that the method is not mutating and the accumulator argument is 
taken as inout.

What is your thought on using the `into` for the proposed variation and 
`mutating` for the variation with an inout accumulator?

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

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Richard Wei via swift-evolution]

Huge +1. We definitely need fixed-size arrays. Just in addition to elegantly 
importing C arrays, this will enable static matrix/tensor shapes for shape-safe 
compute operations like GEMM. Moreover I think we can learn from Rust about 
their recent discussion on constant generics.

-Richard

> On Apr 17, 2017, at 16:07, Jens Persson via swift-evolution 
>  wrote:
> 
> I've used code like the following example in similar situations and I've 
> always (after a lot of profiling, trial and error) managed to get the (ugly) 
> Swift code as fast as the C/C++ code.
> 
> struct UnsafeStatic19x19 {
> var storage: (
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E
> )
> subscript(x: Int, y: Int) -> E {
> get {
> // No index out of bounds check
> var m = self // <-- This workaround will be optimized away.
> return withUnsafeBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> return $0.load(fromByteOffset: byteOffset, as: E.self)
> }
> }
> set {
> withUnsafeMutableBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> $0.storeBytes(of: newValue, toByteOffset: byteOffset, as: 
> E.self)
> }
> }
> }
> }
> 
> It isn't pretty but it works (haven't tried this code example though, but you 
> get the idea).
> 
> 
> I wish it was possible to write something like
> struct StaticArray {
> ...
> }
> instead (a statically allocated array with type-level Count as well as 
> Element).
> 
> /Jens
> 
> 
> On Mon, Apr 17, 2017 at 7:52 PM, Anders Kierulf via swift-evolution 
> > wrote:
> Swift needs a datatype that contains a fixed number of a given type; 
> basically a simple fixed-size array.
> 
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my 
> Go-playing program from C++ to Swift. Performance is crucial for this code, 
> as more simulations lead to better play. After the initial port, the Swift 
> code was more than 10x slower than my C++ code. After several weeks of 
> optimizing, profiling, and digging through disassembly, I’ve gotten to within 
> a factor of 2. Most of that gain came from using the ugly workaround of 
> importing fixed-size arrays from C.
> 
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x N 
> board, so I don’t want to pay the high cost of variable-size data structures 
> in the lowest levels of my app. Most apps are not like this, and most of my 
> app is not, but this kernel of my app needs to be fast. Heap allocations, 
> reference counting, and indirections all slow down the code. I just need a 
> fixed size of memory that I can access like an array, and Swift doesn’t let 
> me do that.
> 
> Workaround: By importing an array from C, I can allocate a blob of memory on 
> the stack or include it in a struct. I can then use UnsafeRawPointer to 
> access that blob like an array (see details in SR-4548). This is ugly, but it 
> works, and it is much faster than using a Swift array. However, I’m stymied 
> by SR-4542, which causes mutability to spread like a plague through client 
> code.
> 
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the parameter 
> to be passed as inout, which means the method must be mutating. 
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
> 
> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
> only allocate memory on the heap, or it can take a given blob of memory and 
> interpret it as something else. What’s missing is a way to allocate typed 
> memory of a certain size on the stack or in a struct. For example, something 

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Michael Ilseman via swift-evolution]

This is the best approach that I’m aware of. It does bake in an ABI assumption 
that the tuple layout will be contiguous and strided/addressable. Monitor 
https://bugs.swift.org/browse/SR-3726 for changes here. Note that you can also 
a little more “pure” in a sense if you construct an UnsafeBufferPointer from 
your UnsafeRawPointer and operate on that. Currently, the compiler does not 
always elide the copy in the getter, see https://bugs.swift.org/browse/SR-4581


> On Apr 17, 2017, at 2:07 PM, Jens Persson via swift-evolution 
>  wrote:
> 
> I've used code like the following example in similar situations and I've 
> always (after a lot of profiling, trial and error) managed to get the (ugly) 
> Swift code as fast as the C/C++ code.
> 
> struct UnsafeStatic19x19 {
> var storage: (
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E
> )
> subscript(x: Int, y: Int) -> E {
> get {
> // No index out of bounds check
> var m = self // <-- This workaround will be optimized away.
> return withUnsafeBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> return $0.load(fromByteOffset: byteOffset, as: E.self)
> }
> }
> set {
> withUnsafeMutableBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> $0.storeBytes(of: newValue, toByteOffset: byteOffset, as: 
> E.self)
> }
> }
> }
> }
> 
> It isn't pretty but it works (haven't tried this code example though, but you 
> get the idea).
> 
> 
> I wish it was possible to write something like
> struct StaticArray {
> ...
> }
> instead (a statically allocated array with type-level Count as well as 
> Element).
> 
> /Jens
> 
> 
> On Mon, Apr 17, 2017 at 7:52 PM, Anders Kierulf via swift-evolution 
> > wrote:
> Swift needs a datatype that contains a fixed number of a given type; 
> basically a simple fixed-size array.
> 
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my 
> Go-playing program from C++ to Swift. Performance is crucial for this code, 
> as more simulations lead to better play. After the initial port, the Swift 
> code was more than 10x slower than my C++ code. After several weeks of 
> optimizing, profiling, and digging through disassembly, I’ve gotten to within 
> a factor of 2. Most of that gain came from using the ugly workaround of 
> importing fixed-size arrays from C.
> 
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x N 
> board, so I don’t want to pay the high cost of variable-size data structures 
> in the lowest levels of my app. Most apps are not like this, and most of my 
> app is not, but this kernel of my app needs to be fast. Heap allocations, 
> reference counting, and indirections all slow down the code. I just need a 
> fixed size of memory that I can access like an array, and Swift doesn’t let 
> me do that.
> 
> Workaround: By importing an array from C, I can allocate a blob of memory on 
> the stack or include it in a struct. I can then use UnsafeRawPointer to 
> access that blob like an array (see details in SR-4548). This is ugly, but it 
> works, and it is much faster than using a Swift array. However, I’m stymied 
> by SR-4542, which causes mutability to spread like a plague through client 
> code.
> 
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the parameter 
> to be passed as inout, which means the method must be mutating. 
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
> 
> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
> only allocate memory on the heap, or it can take a 

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Jens Persson via swift-evolution]

I've used code like the following example in similar situations and I've
always (after a lot of profiling, trial and error) managed to get the
(ugly) Swift code as fast as the C/C++ code.

struct UnsafeStatic19x19 {
var storage: (
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E
)
subscript(x: Int, y: Int) -> E {
get {
// No index out of bounds check
var m = self // <-- This workaround will be optimized away.
return withUnsafeBytes(of: ) {
let byteOffset = MemoryLayout.stride * (x + y*19)
return $0.load(fromByteOffset: byteOffset, as: E.self)
}
}
set {
withUnsafeMutableBytes(of: ) {
let byteOffset = MemoryLayout.stride * (x + y*19)
$0.storeBytes(of: newValue, toByteOffset: byteOffset, as:
E.self)
}
}
}
}

It isn't pretty but it works (haven't tried this code example though, but
you get the idea).


I wish it was possible to write something like
struct StaticArray {
...
}
instead (a statically allocated array with type-level Count as well as
Element).

/Jens


On Mon, Apr 17, 2017 at 7:52 PM, Anders Kierulf via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift needs a datatype that contains a fixed number of a given type;
> basically a simple fixed-size array.
>
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my
> Go-playing program from C++ to Swift. Performance is crucial for this code,
> as more simulations lead to better play. After the initial port, the Swift
> code was more than 10x slower than my C++ code. After several weeks of
> optimizing, profiling, and digging through disassembly, I’ve gotten to
> within a factor of 2. Most of that gain came from using the ugly workaround
> of importing fixed-size arrays from C.
>
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x
> N board, so I don’t want to pay the high cost of variable-size data
> structures in the lowest levels of my app. Most apps are not like this, and
> most of my app is not, but this kernel of my app needs to be fast. Heap
> allocations, reference counting, and indirections all slow down the code. I
> just need a fixed size of memory that I can access like an array, and Swift
> doesn’t let me do that.
>
> Workaround: By importing an array from C, I can allocate a blob of memory
> on the stack or include it in a struct. I can then use UnsafeRawPointer to
> access that blob like an array (see details in SR-4548). This is ugly, but
> it works, and it is much faster than using a Swift array. However, I’m
> stymied by SR-4542, which causes mutability to spread like a plague through
> client code.
>
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the
> parameter to be passed as inout, which means the method must be mutating.
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
>
> Proposal: UnsafeMutablePointer almost provides what I need. However, it
> can only allocate memory on the heap, or it can take a given blob of memory
> and interpret it as something else. What’s missing is a way to allocate
> typed memory of a certain size on the stack or in a struct. For example,
> something like this, with support for subscripts, limited to value types:
>
> var foo = UnsafeMemory(count: 6)
> or
> var bar = FixedSizeArray(repeating: 0, count: 380)
>
> Alternatives:
> (1) C arrays are currently imported as tuples, so extending tuples with
> subscripts and adding a way to create tuples with a specific count of the
> same type could address this need. However, I don’t think this fits well
> with the concept of tuples.
> (2) Changing the Array type to allow a fixed size could be considered in
> the future. ‘count’ and ‘capacity’ would be fixed and only known 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

> the only way to hide one invariant from the other’s methods is to use helper 
> types
Could you elaborate here and give an example that uses such helper types?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[T.J. Usiyan via swift-evolution]

   - What is your evaluation of the proposal?

+ 1

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

Yes

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

I'm not completely sure.

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

Mixed. I won't get into all of the things I wish it did or did not have.

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

I've followed the discussions and read the proposals.

Overall, I don't think that this is necessarily ideal but I do believe that
it would be a net positive for the reasons stated. `private` would become
more common and `fileprivate` less.

On Mon, Apr 17, 2017 at 4:23 PM, Riley Testut via swift-evolution <
swift-evolution@swift.org> wrote:

> I think its important to point out that its more than aesthetics: because
> the simple file and extensions scenario are so common, it forces us to use
> both private and fileprivate fairly regularly, which increases the total
> number of access control to work with on a daily basis. And I think that’s
> the important point. That’s why open is a success IMHO: because it only
> needs to be used rarely, it provided the required functionality without
> increasing the number of access modifiers that needed to be used regularly.
>
>
> I agree 100%. I’ve never been a fan of open, and still disagree with the
> rationale for why it was added. However, because it does follow Swift’s
> progressive disclosure emphasis, and because it does accomplish what it was
> designed to do, I’ve made peace with it.
>
> Fileprivate is different. It was intended to be used rarely, as another
> form of progressive disclosure, and when it *was* used, it had meaning.
> However, as has been discussed many times, this is not the case.
> Fileprivate, for a multitude of reasons, is used far more frequently than
> anticipated (fileprivate is certainly used way more than private in my own
> projects), and as a result *loses *its meaning. When looking at a
> fileprivate declaration, there is no way to know whether it is intended to
> be exposed to separate types, or simply to extensions of the same type.
>
> Again, I personally think access control was far simpler in Swift 2.
> However, because the idea of scoped access clearly has value to many
> developers, I am okay with adding that functionality to the language. By
> allowing extensions to access private variables, fileprivate has actual
> meaning again (which was the original intention) and is also something that
> many developers may never need to use.
>
> FWIW, I really don’t view this proposal as just a stop-gap, I think
> accepting this proposal will genuinely be the *best* option for Swift in
> general. I personally don’t like the idea of renaming private to scoped,
> since I think private and fileprivate are better terms in general. I just
> want private member access in my extensions for God’s sake :^)
>
> On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think its important to point out that its more than aesthetics: because
> the simple file and extensions scenario are so common, it forces us to use
> both private and fileprivate fairly regularly, which increases the total
> number of access control to work with on a daily basis. And I think that’s
> the important point. That’s why open is a success IMHO: because it only
> needs to be used rarely, it provided the required functionality without
> increasing the number of access modifiers that needed to be used regularly.
>
>
>
> ___
> 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-0164: Remove final support in protocol extensions

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md

The review of SE-0164 "Remove final support in protocol extensions” ran from 
April 5...8, 2017. Feedback was light but positive, and the proposal is 
accepted.

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> I think its important to point out that its more than aesthetics: because the 
> simple file and extensions scenario are so common, it forces us to use both 
> private and fileprivate fairly regularly, which increases the total number of 
> access control to work with on a daily basis. And I think that’s the 
> important point. That’s why open is a success IMHO: because it only needs to 
> be used rarely, it provided the required functionality without increasing the 
> number of access modifiers that needed to be used regularly.

I agree 100%. I’ve never been a fan of open, and still disagree with the 
rationale for why it was added. However, because it does follow Swift’s 
progressive disclosure emphasis, and because it does accomplish what it was 
designed to do, I’ve made peace with it.

Fileprivate is different. It was intended to be used rarely, as another form of 
progressive disclosure, and when it was used, it had meaning. However, as has 
been discussed many times, this is not the case. Fileprivate, for a multitude 
of reasons, is used far more frequently than anticipated (fileprivate is 
certainly used way more than private in my own projects), and as a result loses 
its meaning. When looking at a fileprivate declaration, there is no way to know 
whether it is intended to be exposed to separate types, or simply to extensions 
of the same type.

Again, I personally think access control was far simpler in Swift 2. However, 
because the idea of scoped access clearly has value to many developers, I am 
okay with adding that functionality to the language. By allowing extensions to 
access private variables, fileprivate has actual meaning again (which was the 
original intention) and is also something that many developers may never need 
to use.

FWIW, I really don’t view this proposal as just a stop-gap, I think accepting 
this proposal will genuinely be the best option for Swift in general. I 
personally don’t like the idea of renaming private to scoped, since I think 
private and fileprivate are better terms in general. I just want private member 
access in my extensions for God’s sake :^)

> On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution 
>  wrote:
> 
> I think its important to point out that its more than aesthetics: because the 
> simple file and extensions scenario are so common, it forces us to use both 
> private and fileprivate fairly regularly, which increases the total number of 
> access control to work with on a daily basis. And I think that’s the 
> important point. That’s why open is a success IMHO: because it only needs to 
> be used rarely, it provided the required functionality without increasing the 
> number of access modifiers that needed to be used regularly.

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[David Hart via swift-evolution]

> On 17 Apr 2017, at 21:11, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> All right, time to dive in!
> 
> First things first, the “helper visible” row in the table I posted is 
> actually unnecessary: a private helper type can have its visible members 
> unmarked (so, “internal”) and they will be available throughout the file.
> 
> Now, if we believe that cross-type sharing ought be avoided, then the primary 
> place “fileprivate” should occur today is when extending a type in the same 
> file. The one other time it might be unavoidable is when extending an 
> existing type to have an initializer that takes the new type. Thus in 
> “Foo.swift” we might have “extension Bar { init(foo: Foo) … }” and need to 
> see hidden details of Foo.
> 
> Similarly, if we think that unrelated types do not belong together in the 
> same file, then the bottom two rows (which deal with multi-type files) can be 
> expunged as well. After all if there are two types which must not have 
> privileged access to one another, they should go in separate files.
> 
> Thus the only place where “private” need appear today is when protecting 
> members of a type from the rest of that same type. However, as has been 
> mentioned on-list, “private” alone does not achieve sufficient encapsulation 
> for this purpose, because a private variable can be seen in all functions 
> located in the main type declaration.
> 
> Moreover, if a type has two separate invariants, and dedicated methods for 
> interacting with them, the only way to hide one invariant from the other’s 
> methods is to use helper types. It seems that “use a private helper type” 
> should be the preferred way to protect invariants, and if the helper type 
> needs to see the rest of the type’s members then it should be nested.
> 
> Putting everything together, an updated version of the table looks like this, 
> where the “Privileged init” row refers to the scenario described earlier:
> 
> 
> No change
> SE–0159
> SE–0169
> Rename
> Simple file
> private
> private
> private
> private
> Extensions
> fileprivate
> private
> private
> private
> Privileged init
> fileprivate
> private
> fileprivate
> private
> Helper hidden
> private
> no hiding
> private
> scoped
> Invariants
> helper type
> no hiding
> helper type
> helper type
> 
> 
> No change
> 
> If we do not make a change, then we will be stuck using “fileprivate” in 
> perpetuity. This might be a purely aesthetic concern, but I would liken it to 
> a splinter in the finger. Yes it is small, but it hurts every time we touch 
> something with it, and it will keep hurting until we yank it out.

I think its important to point out that its more than aesthetics: because the 
simple file and extensions scenario are so common, it forces us to use both 
private and fileprivate fairly regularly, which increases the total number of 
access control to work with on a daily basis. And I think that’s the important 
point. That’s why open is a success IMHO: because it only needs to be used 
rarely, it provided the required functionality without increasing the number of 
access modifiers that needed to be used regularly.

> The existing meaning for “private” is really only useful to protect members 
> of a helper type. It should not be used for any other purpose because it 
> hamstrings the ability to add extensions, and it is insufficient for true 
> encapsulation outside of helper types.
> 
> SE–0159
> 
> If Swift takes the opinionated stance that one should not put things that 
> need to be hidden from each other in the same file, then SE–0159 is the clear 
> winner. After all, if you can’t hide things from other parts of the file at 
> all, then you won’t be tempted to try and thus you will keep your separate 
> types in separate files. This will also simplify the access control model, 
> making it easier to reason about code and decide which visibility to use.
> 
> It will cause churn, however, as existing projects that use sub-file-level 
> hiding must adapt. In the future a submodule system with a visibility level 
> between “private” and “internal” (perhaps “protected”?) could re-enable the 
> use of helper types (in separate files!) to preserve invariants.
> 
> SE–0169
> 
> If we accept the current proposal, then we will only really need 
> “fileprivate” when extending another type to add something like an 
> initializer which requires privileged access to the main type in a file. 
> Additionally, people will be encouraged to use helper types for encapsulating 
> invariants, because the scope-based “private” of today will no longer be a 
> tempting-but-inferior alternative.
> 
> This option also causes churn, though perhaps in a good way as projects which 
> use “private” for encapsulation must switch to the superior design of helper 
> types. Furthermore, a private helper type can be nested in an extension, so 
> its implementation need not occupy space within the main type declaration. 

Re: [swift-evolution] [pitch] Comparison Reform

[Dave Abrahams via swift-evolution]

on Sun Apr 16 2017, Xiaodi Wu  wrote:

> On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull  wrote:
>
>>
>> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> The point is that, when you manipulate two real numbers, sometimes there
>> is no numeric result. You cannot simply wish this away with a new numeric
>> type because it is not an artifact of _modeling_ real numbers but rather
>> intrinsic to mathematics itself.
>>
>>
>> I agree with the rest of what you said, but I have to disagree on this
>> point.  What I think he is saying is that, in Swift, we really should be
>> representing the NaN case as an optional instead of a magic value on the
>> type itself (similar to how swift uses an optional instead of NSNotFound).
>>
>> In fact, that might be an actual option here.  For ‘Double?’ the compiler
>> could use the bit pattern for NaN internally to represent .none (I believe
>> it does similar tricks to save space with other optional types).  Then
>> disallow reference to NaN within swift code.  Functions or operations which
>> could produce NaN would either have to produce an optional or trap in case
>> of NaN. (e.g. the trig functions would likely return an optional, and 0/0
>> would trap).
>>
>> I think it would actually lead to much better code because the compiler
>> would force you to have to explicitly deal with the case of optional/NaN
>> when it is possible.  Migration would be tricky though...
>>
>
> This is essentially a cosmetic renaming from `Double` to `Double?`. There
> are rules for propagating NaN which numeric algorithms expect. For example,
> `cos(.nan)` returns a value. If your design is to work, every function that
> takes a `Double` will need to take a `Double?`.
>
> Just as Swift String conforms to Unicode standards, FloatingPoint conforms
> to IEEE standards. You'd have to come up with enormous benefits to justify
> breaking that. Doing so for Swift 4 is plainly a non-starter.

+1

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Dave Abrahams via swift-evolution]

on Mon Apr 17 2017, Karl Wagner  wrote:

>> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Fri Apr 14 2017, Karl Wagner  wrote:
>> 
>
>>> Personally, the only valid use-case I can think of is when you want to
>>> initialise an Array’s elements out-of-order - i.e., you want to set a
>>> value for myArray[2] despite myArray[0] and [1] not being
>>> populated. In that case, it would be better to have some kind of
>>> SparseArray type, and for us to have a proper API for unsafe
>>> initialisation of stdlib types.
>> 
>> That is a point in the design space, but there's really no need to
>> expose unsafe initialization in order to get that functionality.  You
>> could simply build ArrayOfOptional that would present the same API as
>> Array but would use a separate inline buffer of bits to denote which
>> of the optionals were non-nil.
>> 
>> -- 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I wasn’t saying a SparseArray type should be part of the standard
> library, but possibly it’s something which could be added to
> Foundation or some 3rd-party “Common Collections” package.

I think it probably should be.

>
>
> Like all data structures, the most efficient one depends on how well
> you can predict what it will store and how it will be
> accessed/modified. A Dictionary might be great for large
> collections that are exceptionally sparse, but it may also be wasteful
> depending on your circumstance.
>
> As for unsafe initialisation, that’s something I badly, badly
> want. 

Me too.  I'm just saying it's an orthogonal concern.

-- 
-Dave

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

Re: [swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu via swift-evolution]

Sorting a collection will not use `<` as the default predicate.

In the Gist, I've outlined a design for `[Double].sorted()` which would
exhibit identical behavior to what is proposed in this thread, but the
design would be different under the hood. In brief, the "go-to" overload
for sorting a collection of comparable elements would be:

sorted(_ sortOrder: SortOrder = .ascending, by comparison:
(Iterator.Element, Iterator.Element) -> Comparison? = `<=>`) ->
[Iterator.Element]

which would notionally use the following for the predicate known today as
`areInIncreasingOrder`:

{
switch sortOrder {
case .ascending:
return comparison($0, $1) == .some(.less) || comparison($1, $1) == .none
case .descending:
return comparison($1, $0) == .some(.less) || comparison($0, $0) == .none
}
}

(We would add an enum `SortOrder` distinct from `Comparison` for reasons
spelled out in the Gist--not really germane to your question, though. And,
although the compiler may or may not do it today, there ought to be no
reason why it cannot optimize away checks for `comparison(a, b) == .none`
if values of the concrete type never compare unordered--i.e. if the
function passed as the second argument to `sorted` returns `Comparison`
instead of `Comparison?`.)

(The `Comparison` instead of `Comparison?` thing, incidentally, is for me
the crux of my alternative design. I'm quite proud of it. It allows us to
recover most (all?) the benefits of knowing at compile time which types are
"partially" comparable and which are not, but *without* having a distinct
protocol named PartiallyComparable. That is, the one protocol `Comparable`
would require a comparison method that returns an instance of type
`Comparison?`. Conforming types that never compare unordered can fulfill
that requirement with a method that returns `Comparison` (non-optional).
Both the compiler and readers can gain something meaningful from that.
Meanwhile, we avoid the disaster of generic algorithms having two different
protocols to choose from and potentially not supporting floating point.)

With this design, each generic function would decide how to handle
unordered comparisons. I believe this to be superior because ordering NaN
greater than all other values produces an acceptable result for `sort` but
a rather unintuitive one for `max`, and there is no reason why we should
have to tolerate that.

Using `sort(by: <)` explicitly with a collection of elements that may
compare unordered will give a compiler warning, as `<` would not satisfy
the semantic requirements for a sort predicate. Nothing will forbid the
user from passing an arbitrary function as a predicate, though, just as we
do not stop someone from writing `sort(by: ==)` today. The warning about
using `<` will be silenced by writing `sort { $0 < $1 }`.

For perfect migration of existing code, `sort(by: <)` can be migrated to
the proposed spelling `sort(by: &<)` and retain Swift 3 behavior in every
way, including the same wonky results with NaN. Otherwise,
`sort(.ascending)` and `sort(.descending)` would be the preferred way to
write the same thing, with more sensible results when sorting NaN.

On Mon, Apr 17, 2017 at 11:40 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Sun Apr 16 2017, Xiaodi Wu  wrote:
>
> > On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution <
> > swift-evolution@swift.org> wrote:
> >
> >> 
> >>
> >>> > I have an incipient idea. It begins with:
> >> >> >
> >> >> > enum ComparisonResult {
> >> >> >   case orderedAscending, orderedSame, orderedDescending, unordered
> >> >> > }
> >> >> >
> >> >> > I am sure there is something I am missing which makes this design a
> >> >> > horrible idea, but I'm interested in hearing them.
> >> >>
> >> >> It's not a horrible idea, but to be fair it's not really a design
> yet,
> >> >> either.  You haven't said anything about what it's supposed to mean,
> how
> >> >> it is supposed to be used, how people write, use, and compose generic
> >> >> algorithms with it, how it deals with floating point, etc.
> >> >>
> >> >
> >> > I've evolved my thinking based on the discussion. Let's see:
> >> >
> >> > ```
> >> > public enum ComparisonResult : Equatable {
> >> >   case orderedAscending, equivalent, orderedDescending, unordered
> >> >   // I have renamed one case, in the hopes of emphasizing that two
> values
> >> >   // that compare `equivalent` are not merely ordered the same, but
> >> should
> >> >   // satisfy the three conditions of an equivalence relation.
> >> > }
> >> > // I will have to leave the question of how to bridge from Obj-C
> >> > // NSComparisonResult up to more capable hands.
> >> >
> >> > public protocol Comparable : Equatable {
> >> >   func compared(to other: Self) -> ComparisonResult
> >> > }
> >> > // This will have to be modified as necessarily to support compiler
> magic
> >> > // necessary for source-compatibility with Swift 3
> >> >
> >> > extension Comparable {
> >> >   

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Karl Wagner via swift-evolution]

> On 17 Apr 2017, at 21:18, Anders Kierulf  wrote:
> 
> 
>> On Apr 17, 2017, at 12:37 PM, Karl Wagner > > wrote:
>> 
>>> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution 
>>> > wrote:
>>> 
>>> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
>>> only allocate memory on the heap, or it can take a given blob of memory and 
>>> interpret it as something else. What’s missing is a way to allocate typed 
>>> memory of a certain size on the stack or in a struct. For example, 
>>> something like this, with support for subscripts, limited to value types:
>> 
>> What happens if you use alloca?
> 
> Doesn’t look like using alloca is recommended in Swift: 
> https://bugs.swift.org/browse/SR-323 
> 
> Also, while it might be used as a hack for stack allocations, it wouldn’t 
> allow inclusion into structs.
> 
> Anders

Huh. That’s weird. I figured in your case, with an integer literal, there 
shouldn’t really be any difference between alloca(19*19) and a stack-allocated, 
fixed-size array like char[19 * 19].

alloca is usually a compiler intrinsic (I suppose that’s why the linker isn’t 
going to find it). It’s definitely a SIL intrinsic. Maybe those two just aren’t 
wired up correctly to support user-code calling “alloca”.

Could certainly be supported - we should probably support alloca directly (as 
we do for malloc), and we could provide a function on UMP which does the same 
thing (allocateNonEscaping?)

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Riley Testut via swift-evolution]

> Dynamic programming comes to mind.


Wouldn’t you then be able to use Array(repeating:count:) and repeat 0 (or 
something else) to achieve this then?

Yes, less performant than alloc’ing array (since we need to fill in default 
values), but doing otherwise would go against Swift’s safety model. If you 
truly wanted that behavior, you can use the UnsafePointer methods anyway 
(AFAIK).

> On Apr 16, 2017, at 9:18 PM, Saagar Jha  wrote:
> 
> Dynamic programming comes to mind.
> 
> Saagar Jha
> 
>> On Apr 16, 2017, at 19:33, Riley Testut > > wrote:
>> 
>> My bad, should have phrased my response better :^)
>> 
>> Under what circumstances would you need to be able to assign elements in an 
>> array out of order, while also requiring Array size/performance? (Genuinely 
>> curious, not trying to attack).
>> 
>> IMO, if the differences between Array and Dictionary would cause that much 
>> of an issue for your implementation, my guess is you have more important 
>> priorities than the need to assign elements out-of-order  I don't think 
>> we'd need to add another type to the standard library for this use case.
>> 
>> On Apr 16, 2017, at 11:22 AM, Saagar Jha > > wrote:
>> 
>>> A Dictionary uses a lot more space than an Array, though, and allow for 
>>> bogus keys like “-1”, etc.
>>> 
>>> Saagar Jha
>>> 
 On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution 
 > wrote:
 
> Personally, the only valid use-case I can think of is when you want to 
> initialise an Array’s elements out-of-order - i.e., you want to set a 
> value for myArray[2] despite myArray[0] and [1] not being populated. In 
> that case, it would be better to have some kind of SparseArray type, and 
> for us to have a proper API for unsafe initialisation of stdlib types. 
 
 Wouldn't the same functionality be accomplished by a Dictionary with Int 
 as the key type?
 
 On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
 > wrote:
 
>> I'd actually say the #1 reason not to add this feature is that a lot of 
>> developers don't seem to understand this, and they're likely to use the 
>> feature to make their code try to continue in the face of programmer 
>> error instead of trapping like it properly should. A program in an 
>> inconsistent state is dangerous; best to stop it quickly before it does 
>> some damage.)
> 
> Right, so I think the reason is actually that a lot of developers don’t 
> understand what an Array is. There are two use-cases for an Array:
> 
> 1) As a string of items, don’t care about the length. The maximum prior 
> knowledge you can have is that the order may or may not be significant. 
> This includes operations like iteration, mapping, reducing and filtering.
> 2) As a string of items of specific length. You have prior knowledge 
> about what you expect to find at each location. This includes operations 
> like random-access subscripting, which is what we’re talking about.
> 
> Basically, the interesting part of a statement such as “let someValue = 
> myArray[2]” is: why index 2? What’s so special about that element; why 
> couldn't someValue be the item at any index N instead? It’s because we 
> know to expect something of special significance at index 2.
> 
> In that case, the only time myArray[2] will fail is when your prior 
> knowledge breaks down. The type-system has no way to encode and check for 
> the length of an Array, and that has allowed somebody to pass in a bad 
> value. So what to do?
> 
> A) If you absolutely require a value for myArray[2]: Insert a 
> precondition check.
> B) If you can still continue without myArray[2]: Check the length of the 
> Array. Your logic will be branching anyway in this case, to account for 
> the value (and subsequent values) being/not being present.
> 
> 
> Personally, the only valid use-case I can think of is when you want to 
> initialise an Array’s elements out-of-order - i.e., you want to set a 
> value for myArray[2] despite myArray[0] and [1] not being populated. In 
> that case, it would be better to have some kind of SparseArray type, and 
> for us to have a proper API for unsafe initialisation of stdlib types. 
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 ___
 swift-evolution mailing list

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> You’re right, I overgeneralized. Let me correct myself:
> 
> From what I’ve seen so far [*], using extensions for "code organization" 
> often results in spaghetti code.
> 
> [*] Observed as a contractor; iOS platform; average Joe's code.


Fair :-)

Another use case for extensions I had forgotten about that I have used 
extensively, however, is using to group private or public members together, and 
have the access control level of the extension apply to each member in the 
extension (by default). Typically, I’ll declare the properties and initializers 
in the main type declaration, and then all public methods I’ll place in a 
“public” extension, and all private methods I’ll place in a “private” 
extension. This IMO is a great win for code readability, and another thing that 
I have lost the ability to do without using file private.

> On Apr 17, 2017, at 1:04 AM, Rudolf Adamkovič  wrote:
> 
> On 17 Apr 2017, at 01:46, Riley Testut  wrote:
>> 
>> So while you personally may not use extensions, calling the use of them 
>> "spaghetti code" is rather misguided IMO.
> 
> You’re right, I overgeneralized. Let me correct myself:
> 
> From what I’ve seen so far [*], using extensions for "code organization" 
> often results in spaghetti code.
> 
> [*] Observed as a contractor; iOS platform; average Joe's code.
> 
> Thanks!
> 
> R+
> 

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

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Anders Kierulf via swift-evolution]

> On Apr 17, 2017, at 12:37 PM, Karl Wagner  wrote:
> 
>> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution 
>> > wrote:
>> 
>> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
>> only allocate memory on the heap, or it can take a given blob of memory and 
>> interpret it as something else. What’s missing is a way to allocate typed 
>> memory of a certain size on the stack or in a struct. For example, something 
>> like this, with support for subscripts, limited to value types:
> 
> What happens if you use alloca?

Doesn’t look like using alloca is recommended in Swift: 
https://bugs.swift.org/browse/SR-323

Also, while it might be used as a hack for stack allocations, it wouldn’t allow 
inclusion into structs.

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Nevin Brackett-Rozinsky via swift-evolution]

All right, time to dive in!

First things first, the “helper visible” row in the table I posted is
actually unnecessary: a private helper type can have its visible members
unmarked (so, “internal”) and they will be available throughout the file.

Now, if we believe that cross-type sharing ought be avoided, then the
primary place “fileprivate” should occur today is when extending a type in
the same file. The one other time it might be unavoidable is when extending
an existing type to have an initializer that takes the new type. Thus in
“Foo.swift” we might have “extension Bar { init(foo: Foo) … }” and need to
see hidden details of Foo.

Similarly, if we think that unrelated types do not belong together in the
same file, then the bottom two rows (which deal with multi-type files) can
be expunged as well. After all if there are two types which must not have
privileged access to one another, they should go in separate files.

Thus the only place where “private” need appear today is when protecting
members of a type from the rest of that same type. However, as has been
mentioned on-list, “private” alone does not achieve sufficient
encapsulation for this purpose, because a private variable can be seen in
all functions located in the main type declaration.

Moreover, if a type has two separate invariants, and dedicated methods for
interacting with them, the only way to hide one invariant from the other’s
methods is to use helper types. It seems that “use a private helper type”
should be the preferred way to protect invariants, and if the helper type
needs to see the rest of the type’s members then it should be nested.

Putting everything together, an updated version of the table looks like
this, where the “Privileged init” row refers to the scenario described
earlier:


*No change*

*SE–0159*

*SE–0169*

*Rename*

*Simple file*

private

private

private

private

*Extensions*

fileprivate

private

private

private

*Privileged init*

fileprivate

private

fileprivate

private

*Helper hidden*

private

no hiding

private

scoped

*Invariants*

helper type

no hiding

helper type

helper type


*No change*

If we do not make a change, then we will be stuck using “fileprivate” in
perpetuity. This might be a purely aesthetic concern, but I would liken it
to a splinter in the finger. Yes it is small, but it hurts every time we
touch something with it, and it will keep hurting until we yank it out.

The existing meaning for “private” is really only useful to protect members
of a helper type. It should not be used for any other purpose because it
hamstrings the ability to add extensions, and it is insufficient for true
encapsulation outside of helper types.

*SE–0159*

If Swift takes the opinionated stance that one should not put things that
need to be hidden from each other in the same file, then SE–0159 is the
clear winner. After all, if you can’t hide things from other parts of the
file at all, then you won’t be tempted to try and thus you will keep your
separate types in separate files. This will also simplify the access
control model, making it easier to reason about code and decide which
visibility to use.

It will cause churn, however, as existing projects that use sub-file-level
hiding must adapt. In the future a submodule system with a visibility level
between “private” and “internal” (perhaps “protected”?) could re-enable the
use of helper types (in separate files!) to preserve invariants.

*SE–0169*

If we accept the current proposal, then we will only really need
“fileprivate” when extending another type to add something like an
initializer which requires privileged access to the main type in a file.
Additionally, people will be encouraged to use helper types for
encapsulating invariants, because the scope-based “private” of today will
no longer be a tempting-but-inferior alternative.

This option also causes churn, though perhaps in a good way as projects
which use “private” for encapsulation must switch to the superior design of
helper types. Furthermore, a private helper type can be nested in an
extension, so its implementation need not occupy space within the main type
declaration. It is worth noting than a private nested helper type cannot be
extended, and is thus guaranteed to be defined entirely within a single
code block, because it is only visible in the outer type and extensions
cannot be nested.

The access control model becomes more complex to explain, though perhaps
simpler to understand. However, one concern is that SE–0169 might
effectively encourage people to place unrelated types in the same file.
After all, one might reason, why would they have carved out this
weirdly-specific meaning for “private” if they didn’t expect and intend for
me to put several different types in a single file?

*Rename*

If we change the spelling of “private” to “scoped” and of “fileprivate” to
“private”, then there will be no extra work for developers because the
semantics are identical and migration can be 

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[David Sweeris via swift-evolution]

> On Apr 17, 2017, at 10:52 AM, Anders Kierulf via swift-evolution 
>  wrote:
> 
> Swift needs a datatype that contains a fixed number of a given type; 
> basically a simple fixed-size array.
> 
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my 
> Go-playing program from C++ to Swift. Performance is crucial for this code, 
> as more simulations lead to better play. After the initial port, the Swift 
> code was more than 10x slower than my C++ code. After several weeks of 
> optimizing, profiling, and digging through disassembly, I’ve gotten to within 
> a factor of 2. Most of that gain came from using the ugly workaround of 
> importing fixed-size arrays from C. 
> 
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x N 
> board, so I don’t want to pay the high cost of variable-size data structures 
> in the lowest levels of my app. Most apps are not like this, and most of my 
> app is not, but this kernel of my app needs to be fast. Heap allocations, 
> reference counting, and indirections all slow down the code. I just need a 
> fixed size of memory that I can access like an array, and Swift doesn’t let 
> me do that.
> 
> Workaround: By importing an array from C, I can allocate a blob of memory on 
> the stack or include it in a struct. I can then use UnsafeRawPointer to 
> access that blob like an array (see details in SR-4548). This is ugly, but it 
> works, and it is much faster than using a Swift array. However, I’m stymied 
> by SR-4542, which causes mutability to spread like a plague through client 
> code.
> 
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the parameter 
> to be passed as inout, which means the method must be mutating. 
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
> 
> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
> only allocate memory on the heap, or it can take a given blob of memory and 
> interpret it as something else. What’s missing is a way to allocate typed 
> memory of a certain size on the stack or in a struct. For example, something 
> like this, with support for subscripts, limited to value types:
> 
>var foo = UnsafeMemory(count: 6)
> or
>var bar = FixedSizeArray(repeating: 0, count: 380)
> 
> Alternatives:
> (1) C arrays are currently imported as tuples, so extending tuples with 
> subscripts and adding a way to create tuples with a specific count of the 
> same type could address this need. However, I don’t think this fits well with 
> the concept of tuples.
> (2) Changing the Array type to allow a fixed size could be considered in the 
> future. ‘count’ and ‘capacity’ would be fixed and only known to the compiler, 
> not stored with the data. However, I suspect the consequences would be 
> far-reaching, and thus I don’t see this happening soon.
> 
> An UnsafeMemory type would be a limited addition that fits in well with the 
> existing low-level Pointer module, and fills a gap in the capabilities of 
> Swift. The Pointer module helps implement low-level, performance-critical 
> code, and not being able to create data on the stack is a serious omission. 
> Jumping through C hoops is not a solution.

Up until 30 seconds ago, I'd thought there was a way to initialize an array 
with a pre-existing buffer. Apparently not, though.

There’s currently no way to restrict a generic parameter to be a value type. I 
suspect this is at least partly because `struct` doesn’t make any promises 
about whether its properties have value or reference semantics (but unless I’m 
forgetting something, that’s just a guess on my part). The topic of an 
exclusively value-semantics type, “simplestruct” for lack of a better term, has 
come up at least once. IIRC it was deemed to not provide enough of a benefit to 
justify the added language complexity (although I have a vague memory that it 
was only brought in connection with another topic, as it is here, so maybe if 
it was its own proposal the results would been different). Personally, I don’t 
think it adds all that much complexity (from the developer's PoV… dunno about 
the compiler), and barring some other reason would be in favor of it. That’s 
just one opinion, though (and one of someone who’s not all that experienced, as 
well).

Both of your alternatives have been brought up before. My recollection is we 
tentatively* decided that it’d be better to add fixed-size arrays and change 
how C arrays are imported, but that conversation was a *long* time ago, before 
we were as worried about backwards compatibility. Neither alternative has come 
to a formal proposal, though, because they were deemed out-of-scope** before 
things got that far. I don’t think either has come up since phase 2 started, 
though... Maybe it’d be worth revisiting the ideas?

- Dave Sweeris

* because of **
___
swift-evolution mailing list

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

[Karl Wagner via swift-evolution]

> On 17 Apr 2017, at 19:52, Anders Kierulf via swift-evolution 
>  wrote:
> 
> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
> only allocate memory on the heap, or it can take a given blob of memory and 
> interpret it as something else. What’s missing is a way to allocate typed 
> memory of a certain size on the stack or in a struct. For example, something 
> like this, with support for subscripts, limited to value types:

What happens if you use alloca?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Karl Wagner via swift-evolution]

> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Apr 14 2017, Karl Wagner  wrote:
> 
>> Personally, the only valid use-case I can think of is when you want to
>> initialise an Array’s elements out-of-order - i.e., you want to set a
>> value for myArray[2] despite myArray[0] and [1] not being
>> populated. In that case, it would be better to have some kind of
>> SparseArray type, and for us to have a proper API for unsafe
>> initialisation of stdlib types.
> 
> That is a point in the design space, but there's really no need to
> expose unsafe initialization in order to get that functionality.  You
> could simply build ArrayOfOptional that would present the same API as
> Array but would use a separate inline buffer of bits to denote which
> of the optionals were non-nil.
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I wasn’t saying a SparseArray type should be part of the standard library, but 
possibly it’s something which could be added to Foundation or some 3rd-party 
“Common Collections” package.

Like all data structures, the most efficient one depends on how well you can 
predict what it will store and how it will be accessed/modified. A 
Dictionary might be great for large collections that are exceptionally 
sparse, but it may also be wasteful depending on your circumstance.

As for unsafe initialisation, that’s something I badly, badly want. Basically, 
I want to be able to tell Array or String to allocate an internal buffer of 
size N, then fill it myself (perhaps using POSIX functions like read or recv, 
or concurrently with no guaranteed order), and tell it how much data I actually 
initialised. Then you could stroll off in to the sunshine with a real Array 
or String that you read from a file or socket without copying. That’s the point 
when Array becomes as good as a C Array for me.

Of course, String being UTF16 would be an issue. There aren’t many files stored 
in UTF16, and even for sockets, if the server isn’t also Swift, you’ll probably 
be getting fed UTF8. You will still need to copy as you read in to a buffer of 
UTF8 before initialising the String’s backing storage with the corresponding 
UTF16 code-units. Perhaps the new String model/unicode encodings can help make 
that easier in some way.

Still, unsafe initialisation would be totally badass; In Objective-C, NSString 
needs to have a special method to read its data from a file to handle that one 
particular use-case, so it can use private knowledge to more efficiently read 
the file directly in to an internal buffer (I presume…). The alternative is to 
read the bytes in as an NSData and copy them in to an NSString (before throwing 
the NSData away, most likely). In Swift, we can have a better, more generalised 
solution.

- Karl

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

[swift-evolution] [Pitch] Swift needs fixed-size array

[Anders Kierulf via swift-evolution]

Swift needs a datatype that contains a fixed number of a given type; basically 
a simple fixed-size array.

Motivation: I’ve been porting code for Monte Carlo Tree Search in my Go-playing 
program from C++ to Swift. Performance is crucial for this code, as more 
simulations lead to better play. After the initial port, the Swift code was 
more than 10x slower than my C++ code. After several weeks of optimizing, 
profiling, and digging through disassembly, I’ve gotten to within a factor of 
2. Most of that gain came from using the ugly workaround of importing 
fixed-size arrays from C. 

My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x N 
board, so I don’t want to pay the high cost of variable-size data structures in 
the lowest levels of my app. Most apps are not like this, and most of my app is 
not, but this kernel of my app needs to be fast. Heap allocations, reference 
counting, and indirections all slow down the code. I just need a fixed size of 
memory that I can access like an array, and Swift doesn’t let me do that.

Workaround: By importing an array from C, I can allocate a blob of memory on 
the stack or include it in a struct. I can then use UnsafeRawPointer to access 
that blob like an array (see details in SR-4548). This is ugly, but it works, 
and it is much faster than using a Swift array. However, I’m stymied by 
SR-4542, which causes mutability to spread like a plague through client code.

(SR-4542: Calling a function taking an UnsafeRawPointer forces the parameter to 
be passed as inout, which means the method must be mutating. 
UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)

Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
only allocate memory on the heap, or it can take a given blob of memory and 
interpret it as something else. What’s missing is a way to allocate typed 
memory of a certain size on the stack or in a struct. For example, something 
like this, with support for subscripts, limited to value types:

var foo = UnsafeMemory(count: 6)
or
var bar = FixedSizeArray(repeating: 0, count: 380)

Alternatives:
(1) C arrays are currently imported as tuples, so extending tuples with 
subscripts and adding a way to create tuples with a specific count of the same 
type could address this need. However, I don’t think this fits well with the 
concept of tuples.
(2) Changing the Array type to allow a fixed size could be considered in the 
future. ‘count’ and ‘capacity’ would be fixed and only known to the compiler, 
not stored with the data. However, I suspect the consequences would be 
far-reaching, and thus I don’t see this happening soon.

An UnsafeMemory type would be a limited addition that fits in well with the 
existing low-level Pointer module, and fills a gap in the capabilities of 
Swift. The Pointer module helps implement low-level, performance-critical code, 
and not being able to create data on the stack is a serious omission. Jumping 
through C hoops is not a solution.

Anders Kierulf

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

Re: [swift-evolution] [pitch] Comparison Reform

[Dave Abrahams via swift-evolution]

on Sun Apr 16 2017, Xiaodi Wu  wrote:

> On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 
>>
>>> > I have an incipient idea. It begins with:
>> >> >
>> >> > enum ComparisonResult {
>> >> >   case orderedAscending, orderedSame, orderedDescending, unordered
>> >> > }
>> >> >
>> >> > I am sure there is something I am missing which makes this design a
>> >> > horrible idea, but I'm interested in hearing them.
>> >>
>> >> It's not a horrible idea, but to be fair it's not really a design yet,
>> >> either.  You haven't said anything about what it's supposed to mean, how
>> >> it is supposed to be used, how people write, use, and compose generic
>> >> algorithms with it, how it deals with floating point, etc.
>> >>
>> >
>> > I've evolved my thinking based on the discussion. Let's see:
>> >
>> > ```
>> > public enum ComparisonResult : Equatable {
>> >   case orderedAscending, equivalent, orderedDescending, unordered
>> >   // I have renamed one case, in the hopes of emphasizing that two values
>> >   // that compare `equivalent` are not merely ordered the same, but
>> should
>> >   // satisfy the three conditions of an equivalence relation.
>> > }
>> > // I will have to leave the question of how to bridge from Obj-C
>> > // NSComparisonResult up to more capable hands.
>> >
>> > public protocol Comparable : Equatable {
>> >   func compared(to other: Self) -> ComparisonResult
>> > }
>> > // This will have to be modified as necessarily to support compiler magic
>> > // necessary for source-compatibility with Swift 3
>> >
>> > extension Comparable {
>> >   public static func == (lhs: Self, rhs: Self) -> Bool {
>> > let comparison = lhs.compared(to: rhs)
>> > precondition(comparison != .unordered)
>> > return comparison == .equivalent
>> >   }
>> >
>> >   public static func < (lhs: Self, rhs: Self) -> Bool {
>> > let comparison = lhs.compared(to: rhs)
>> > precondition(comparison != .unordered)
>> > return comparison == .orderedAscending
>> >   }
>> >   // etc.
>> >
>> >   // Something I thought I'd never want to see, but on reflection not
>> > terrible:
>> >   public static func &== (lhs: Self, rhs: Self) -> Bool {
>> > return lhs.compared(to: rhs) == .equivalent
>> >   }
>> >
>> >   public static func &< (lhs: Self, rhs: Self) -> Bool {
>> > return lhs.compared(to: rhs) == .orderedAscending
>> >   }
>> >   // etc.
>> > }
>> >
>> > extension FloatingPoint : Comparable {
>> >   public func compared(to other: Self) -> ComparisonResult {
>> > if isNaN || other.isNaN { return .unordered }
>> > if isLess(than: other) { return .orderedAscending }
>> > if other.isLess(than: self) { return .orderedDescending }
>> >
>> > // On reconsideration, probably actually least surprising if +0.0 ==
>> > -0.0
>> > // no matter what. It does not matter that division can give
>> different
>> > // results for two equivalent values, only that the three rules of an
>> > // equivalence relation will hold, and it does.
>> > //
>> > // If a user is really savvy to the sign of zero, there is
>> > FloatingPoint.sign,
>> > // which is necessary in any case for working with FP operations that
>> > // distinguish between +0 and -0. I can't think of a generic
>> algorithm
>> > over
>> > // all Comparable types that could make use of the distinction
>> between
>> > +0
>> > // and -0.
>> > return .equivalent
>> >   }
>> > }
>> > ```
>> >
>> > In this design, `==`, `<`, etc. correspond to IEEE "signaling" operators,
>> > while `&==`, `&<`, etc. correspond to C-style operators, which IEEE calls
>> > "quiet" and actually notates using "?==", "?<", etc.
>>
>> It's interesting, but what's missing here is a description of the user
>> model.  How do users program with this design?  What should my
>> expectations be w.r.t. generic algorithms like sort() and floating point
>> numbers, particularly NaN?  If, as I suspect, sorting a collection
>> containing NaN is going to trap (unless the collection has only one
>> element?), why is that the right behavior?
>
> I've spent some time fleshing out this idea:
> https://gist.github.com/xwu/e864ffdf343160a8a26839388f677768

More interesting still, but you still failed to answer the final
question above.

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Dave Abrahams via swift-evolution]

on Fri Apr 14 2017, Karl Wagner  wrote:

> Personally, the only valid use-case I can think of is when you want to
> initialise an Array’s elements out-of-order - i.e., you want to set a
> value for myArray[2] despite myArray[0] and [1] not being
> populated. In that case, it would be better to have some kind of
> SparseArray type, and for us to have a proper API for unsafe
> initialisation of stdlib types.

That is a point in the design space, but there's really no need to
expose unsafe initialization in order to get that functionality.  You
could simply build ArrayOfOptional that would present the same API as
Array but would use a separate inline buffer of bits to denote which
of the optionals were non-nil.

-- 
-Dave

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

Re: [swift-evolution] [pitch] Comparison Reform

[Joe Groff via swift-evolution]

> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> For example, I expect `XCTAssertEqual(_:_:)` to be vended 
> as part of XCTest, in order to make sure that 
> `XCTAssertEqual(resultOfComputation, Double.nan)` always fails.

Unit tests strike me as an example of where you really *don't* want level 1 
comparison semantics. If I'm testing the output of an FP operation, I want to 
be able to test that it produces nan when I expect it to, or that it produces 
the right zero.

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

Re: [swift-evolution] Turning access control into SEP ;-)

[Andrey Fidrya via swift-evolution]

I use this access control model. As I usually split large classes into multiple 
files using extensions, marking members "fileprivate" or "private" initially is 
pointless.

Of course, "private" can be used for small classes which don't need to be 
split, but that would be inconsistent. Also the code looks tidy without being 
cluttered with "private" in every declaration.

It's too bad that compiler can't protect classes inside the same module from 
accessing implementation details of other classes using this approach, but I 
sacrificed this for freely splitting code between files. Imo, ideal access 
model for this coding style would be "type+extensions" visibility default with 
explicit "module" ("internal") and "public" modifiers.

Andrey

> On 17 Apr 2017, at 14:17, Tino Heth via swift-evolution 
>  wrote:
> 
> I don't remember the exact location, but there have been several 
> contributions from active members of the community who stated they would be 
> fine with just two levels of access control — but I haven't seen this 
> standpoint discussed at all.
> Most likely, that is because it contradicts the perceived spirit on 
> swift-evolution, but who knows, maybe this opinion isn't as isolated as we 
> think?
> To be honest, I don't expect that such a drastic simplification would be 
> seriously considered, but I think it's a good exercise to take such an 
> extreme perspective.
> 
> [If anyone would like to participate in this experiment, you may prefer to 
> skip the rest for now to avoid bias ;-) ]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [personal results start here]
> 
> I don't need access control as a tool to enforce my opinion onto others, so 
> I'm not generally opposed to a compiler-orientated model, where access 
> limitation would only be used to allow better optimisation.
> 
> What I don't want to loose is a way to document intensions which helps users 
> of an API — but this could be something different than a compilation error 
> that tells me I'm trying to call a method that I'm not allowed to use.
> In my day to day routine, the language level actually isn't that important:
> When I work in an environment that is new to me, a method that is missing in 
> autocompletion is as protected as a private member, and it's similar for 
> overrides.
> So I would be fine with a set of annotations that are ignored by the 
> compiler, but used by the IDE. Actually, such an approach could have saved me 
> from stupid errors in the past, because the compiler only knows if I'm 
> allowed or forbidden to do something (anyone else ever had fun with 
> UITableView.didDeselectRowAtIndexPath? Alphabetical order is a really 
> inconvenient sometimes, and there is no way for the compiler to detect such 
> problems reliably).
> 
> ___
> 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-0168: Multi-Line String Literals

[Vladimir.S via swift-evolution]

On 16.04.2017 0:22, Adrian Zubarev via swift-evolution wrote:
Hi guys, I am, and also my English is, at my most limit fighting in this 
conversation. ;-)


I would not support, v1 v2 and v3 at all and would wish these options to be 
completely banned for a nice and simple model, even if all of the options can be 
implemented and might look OKAY for some specific examples. IMHO these mixed options 
overcomplicating the model.


I’d love to see the authors revision the proposal tackling the simple model I 
initially pushed forward, where I revised my personal opinion about the last content 
line, but most of you felt comfortable with.


 1. Single-line expression.
 2. Multi-line expression with no text directly after/before the delimiters 
(not even
a backslash like |"""\|).
 3. Each line adds a new line (multi-line).
 4. Disabling with the backslash.
 5. Emitting a warning when trailing whitespaces are present but no |\| is 
found at
the end of the same line. + Fix-it with |\n\|
 6. Not sure about the indent algorithm (I prefer the calculation of the 
prefix).


My +1. Easy to remember and follow rules, no un-needed confusion points, nice looking 
syntax for common cases but still flexible enough for other use-cases.


About indent algorithm.. IMO we need the ability to have leading whitespaces for 
*each* multi-line's line, so in such case we need the ability to specify the number 
of whitespaces we want to keep for each, so for now the best option is determinate 
the number of leading whitespaces by position of closing delimiter """.





I also would be pleased when the authors could put the model I would prefer in the 
alternative section, so that the majority and the core team could have the chance to 
decide for the better one during the next review run.


Thanks to everyone for tackling the topic forward. ;)



--
Adrian Zubarev
Sent with Airmail

Am 15. April 2017 um 21:56:27, Ricardo Parada (rpar...@mac.com 
) schrieb:




On Apr 15, 2017, at 3:28 PM, Thorsten Seitz > wrote:



Here is another example:

case .isExprSameType(let from, let to):
return """checking a value with optional type \(*from*)\
against dynamic type\(*to*) \
succeeds whenever the value is non-'nil'; \
did you mean to use '!= nil'?\
"""



This only works because the lines have been indented by hand to match correctly 
which would not be the case with standard indentation used in a code editor which 
is a fixed multiple of spaces or tabs: the example had to add 2 spaces to the 2 
tabs in this example to fix the indentation (requiring 8-space-tabs). In reality 
the example would look like follows (assuming 4-space-indentation but the problem 
is the same for other indentations):


case .isExprSameType(let from, let to):
return """checking a value with optional type \(*from*)\
against dynamic type\(*to*) \
  succeeds whenever the value is non-'nil'; \
  did you mean to use '!= nil'?\
"""


That is perfectly fine too. I don't find this style confusing.  The 2nd, 3rd and 
4th lines are stripped of their indentation according to the closing delimiter. And 
that is it.



I personally do not find this style confusing at all.


The confusion arises over the leading newline: why does text directly following 
the opening triple quote have a newline while an empty line after the opening 
triple quote does not have a newline?


I think it is a good thing to have *the* *option* to start the line of text 
immediately after the opening delimiter or on the next line.


Regards,
Ricardo




___
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] Turning access control into SEP ;-)

[Tino Heth via swift-evolution]

I don't remember the exact location, but there have been several contributions 
from active members of the community who stated they would be fine with just 
two levels of access control — but I haven't seen this standpoint discussed at 
all.
Most likely, that is because it contradicts the perceived spirit on 
swift-evolution, but who knows, maybe this opinion isn't as isolated as we 
think?
To be honest, I don't expect that such a drastic simplification would be 
seriously considered, but I think it's a good exercise to take such an extreme 
perspective.

[If anyone would like to participate in this experiment, you may prefer to skip 
the rest for now to avoid bias ;-) ]















[personal results start here]

I don't need access control as a tool to enforce my opinion onto others, so I'm 
not generally opposed to a compiler-orientated model, where access limitation 
would only be used to allow better optimisation.

What I don't want to loose is a way to document intensions which helps users of 
an API — but this could be something different than a compilation error that 
tells me I'm trying to call a method that I'm not allowed to use.
In my day to day routine, the language level actually isn't that important:
When I work in an environment that is new to me, a method that is missing in 
autocompletion is as protected as a private member, and it's similar for 
overrides.
So I would be fine with a set of annotations that are ignored by the compiler, 
but used by the IDE. Actually, such an approach could have saved me from stupid 
errors in the past, because the compiler only knows if I'm allowed or forbidden 
to do something (anyone else ever had fun with 
UITableView.didDeselectRowAtIndexPath? Alphabetical order is a really 
inconvenient sometimes, and there is no way for the compiler to detect such 
problems reliably).

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

> Also, while some have mentioned that this adds complexity to the access 
> control system because types are now a factor, to that I say: this is purely 
> a theoretical issue. In practice, developers don't care that this is case, 
> and just care that the access control logic makes sense when using it. As 
> someone who's had to explain why fileprivate is necessary many times to new 
> Swift developers when using extensions, I can assure you that using this 
> proposed private definition makes more intuitive sense to them.
Well, I guess than it would be the best to ignore private completely and only 
teach the model of Swift 2:
Without private, access control is completely separated from from extensions 
(mixing concerns rarely makes things easier), and you save yourself from the 
questions why extension A can't see a property declared five lines above, 
wheres extension B at the bottom of the same file has no such problem.
No one really knows what's better for the "average Swift programmer", and no 
matter how many newcomers you have met, I doubt it is a significant share of 
all Swift users out there.

Sticking to facts, we have a steady increase of access control complexity, and 
this is pepped by adding special rules to work around perceived or real 
inconveniences.
SE-0169 aims to be a small change with minimal impact, but those pile up 
easily...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rudolf Adamkovič via swift-evolution]

On 17 Apr 2017, at 01:46, Riley Testut  wrote:
> 
> So while you personally may not use extensions, calling the use of them 
> "spaghetti code" is rather misguided IMO.

You’re right, I overgeneralized. Let me correct myself:

From what I’ve seen so far [*], using extensions for "code organization" often 
results in spaghetti code.

[*] Observed as a contractor; iOS platform; average Joe's code.

Thanks!

R+

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

>> And it's a style that is so widely used by the Swift community that even if 
>> you think it's a bad practice does not change the fact that many people use 
>> that style and that the current access level rules don't play well with them.
> 
> Just because it’s widely used doesn’t mean it’s a good idea. Remember, Swift 
> is still very young. SOLID and other “old school" OOP principles are way 
> older and proven to work at this point. For example, as an iOS contractor, I 
> very, very often see extensions used for “code organization” of massive view 
> controllers. It’s easy to do and looks pretty. But that’s just putting 
> lipstick on a pig. Of course, this is just anecdotal evidence and a personal 
> opinion. By no means I’m saying I’m right. Just sharing my view and voting. I 
> may be wrong of course, especially among very smart people that are here.

I share your concerns: There is no proof that using extensions to group 
protocol-methods has any benefit, and there is no proof for the contrary.
Looking at the status quo, we see encouragement for this practice from the 
creators of Swift, which is merely copied by authors of styleguides and finally 
consumed by the "average coder".
So, is it that surprising that many people adopt that concept?

SE-0169 is based on little more that than a gut feeling how code should be 
organised — and even the smartest minds can't always trust their intuition (I 
hope they won't disagree with this claim ;-).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution