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

[Tino Heth via swift-evolution]

-1 (strong)

I think I've read all messages and haven't much to add — so just to sum up my 
concerns in order:
— It makes access control more complicated
For me, it's not about the complexity itself (it's not terrible huge, after 
all), but I believe in the beauty of simplicity, which is already quite flawed.
— It adds no power to the language
The proposal solves no real problem, but rather encourages a certain style of 
programming, which is quite popular among authors of styleguides, but has no 
clear net gain.
— It diminishes the need for fileprivate without making it redundant
It would be nice to get rid of an access level, but having four common ones and 
fileprivate as an exotic outlier doesn't feel right for me.
— It is a mockery for SE-0025
I never liked "new private", but it was decided that this sort of encapsulation 
is important enough to justify 33% increase in the number of access levels, so 
I don't like to see this watered down
— It is a breaking change
For me personally, that doesn't really count as an argument on its own, and I 
would gladly take the inconvenience of incompatibility in exchange for a tiny 
improvement of the language; but in combination with the other points, it 
increases opposition.

I spend some time thinking about nested extensions (which would achieve the 
goal of this proposal naturally) and think that SE-0169 would lead to some 
questionable possibilities of short-circuiting access control:

class Outer {
private class Inner {
private var x = 0
}
}

/*
.
.
.
*/

extension Outer.Inner {
public func f() {
print(x)
}
}

As I read the proposal, there is no doubt that this would be allowed — but 
without that detailed information, I'm not sure if anybody would expect that 
two levels of private still is not enough to keep something secret…

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor  wrote:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 

> What is your evaluation of the proposal?
I've interrogated this proposal pretty thoroughly in the draft threads, and 
overall, I'd say it's excellent. I don't agree with every decision, but I think 
they are all very defensible.

If there is one thing I'm still not satisfied with, it's the large number of 
overloaded `encode` and `decode` methods; I think this design puts far too much 
effort into optimizing performance for rarely used types like `UInt16` when it 
would be better to write smaller, more compact interfaces that are easier to 
wrap your head around.

I'm also not too happy with the use of `mutating` on the containers. Some 
containers require mutability, others don't, it's impossible to remember which 
ones are which, and Swift will complain about you using `var` instead of `let` 
or vice versa if you get it wrong.

But these are minor nitpicks. This proposal will be a huge boon to Swift 
development and I support it wholeheartedly.

Incidentally, I think that in the future, we should try to infuse elements of 
alternative design 5 (where containers are scoped by closures). This points the 
way to a feature we ought to add to Swift: An `@once` annotation which promises 
that a closure parameter is executed exactly once, and (if the closure is not 
`@escaping`) can therefore be trusted by the definite initialization checker. 
We can then introduce closure-based versions of the container-fetching methods 
and have a nice, backwards-compatible improvement in ergonomics.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Absolutely. The lack of a good serialization solution is a major issue.

> Does this proposal fit well with the feel and direction of Swift?
Mostly. There are things that don't, like the large and arbitrary set of 
primitive types and the treatment of Optionals, but I think these design 
decisions are defensible.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I think this is a much better design than NSCoding in many ways.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I think it's fair to say: A lot.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I have not voted in favor or against the proposal. I have been reading a lot 
> of responses but I agree with Tony. 
> 
> When I started reading the proposal everything was more or less fine half way 
> through the proposal because it was reverting private to fileprivate between 
> the type and its extensions within the same file. I said, if you think of the 
> type and its extensions as a unit then it makes sense. I can explain that. 
> 
> Then it started describing a different behavior among the extensions located 
> in a file separate from the file containing the definition of the type. That 
> just started a whole debate inside my head and I understand the passionate 
> responses on both sides. 
> 
> But then I imagined myself explaining this to someone new to Swift and it 
> just doesn't seem right. If it becomes convoluted then that's a red flag that 
> it does not belong in Swift. 

I understand what you are saying and I wouldn't be against relaxing that 
requirement (not talking for Chris here).

The model would change from "Types share scopes with their extensions in the 
same file the type was defined" to "Types and their extensions share the same 
scope in each file".

> I agree fileprivate may be ugly to some and it may be more popular than 
> private. But I think fileprivate is very clear. I know what it does from its 
> name without having to ask. And private behaves the way private works in 
> other languages. 
> 
> Regards
> 
> 
>> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
 But even outside the generated code use cases, it's nice to just be able 
 to implement helpers or additional "convenience" conformances in separate 
 files named appropriately (like "Type+Protocol.swift" or 
 "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>>> 
>>> No doubt about the usefulness of having separate files with extensions here
>>> 
 If nothing else, nested extensions could save those who actually don't 
 care much about such issues from another breaking change in Swift — and 
 imho it adds consistency:
 We can nest types, so why can't we nest extensions?
 
 Because types and extensions are quite different beasts, so something that 
 applies to one doesn't necessarily apply to the other.
>>> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types...
>> 
>> They shouldn't be. That's why I don't support SE-0169 either, because it 
>> would allow extensions to extend the *scope* rather than the *type*, but 
>> only within the same file. I think that's fundamentally broken.
>> 
>> But my comment wasn't about curly braces—it was about types vs. extensions. 
>> For example, you can declare local types within a function, but you can't 
>> extend a type within a function (nor do I think it would be a good idea).
>> 
>>  
>>> 
 I don't think that holds its weight. This feels like another case of 
 "let's try to satisfy everyone who's unhappy with some part of Swift 
 visibility by changing a completely different feature to make things fall 
 into place", which I don't think is a sound motivation or design 
 principle. The example you posted in your initial message weaves multiple 
 types/nesting levels together in a way that looks *incredibly* difficult 
 to follow/parse to even an experienced user of the language.
>>> 
>>> Did you noticed that I started this example as mockery? In real life, I 
>>> would hopefully never nest more than once… and do you think sprinkling 
>>> parts of class over the project is easier to follow?
>> 
>> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* parts 
>> of a type across the project, but if there's some kind of "aside" 
>> functionality that doesn't depend on private knowledge of the type, then I 
>> find it to be a nice feature to have. It requires me to have reasonable 
>> names to my source files, but that's not a significant burden.
>> 
>>  
>>> 
 Everyone seems to be striving for a "perfect" level of access control that 
 lets individual types/members dictate precisely what other types/members 
 can access them. I'm not sure if that perfection is attainable or not, but 
 even if it is, I don't think it's something we should strive for. I'd 
 rather have a simple visibility model that leaks a little than an 
 air-tight model that allows people to write overly complicated code for 
 the sake of fine-tuning access.
>>> 
>>> I had no desire to change the model of Swift 2 — but apparently, others 
>>> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
>>> model like nesting over a complic

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]

As far as I'm aware, eliminating retroactive conformances is a non-starter.


On Mon, Apr 10, 2017 at 21:44 Howard Lovatt  wrote:

> @Xiaodi,
>
> You make two drugs.
>
> 1. Deliberately making retroactive conformance outside of the file in
> which the type is declared illegal because of the problems it causes. See
> all the questions on Swift Users and watch people learning Swift get caught
> out.
>
> 2. Outside of the file in which the type is declared the static final
> extension is restricted to internal or fileprivate so that multiple modules
> can add static final extensions without clashes.
>
>
> -- Howard.
>
> On 11 Apr 2017, at 8:51 am, Xiaodi Wu  wrote:
>
> On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In response to Jordan Rose's comment I suggest the following change:
>
> Proposal: Split extension usage up into implementing methods and adding
> static functions
>
>
> Currently extension methods are confusing because they have different
> dispatch rules for the same syntax. EG:
>
>
> protocol P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
> struct S: P {
>
> func m() { print("S.m") }
>
> }
>
> val p: P = S() // Note typed as P
>
> p.m() // Surprisingly prints P.m even though S implements its own m
>
>
> This is incorrect. This prints "S.m", not "P.m".
>
>
> val s = S() // Note typed as S
>
> s.m() // Prints S.m as expected
>
>
> This proposal cures the above problem by separating extension methods into
> two seperate use cases: implementations for methods and adding static
> functions.
>
>
> First implementing methods.
>
>
> If the extension is in the same file as the protocol/struct/class
> declaration then it implements the methods and is dispatched using a
> Vtable. EG:
>
>
> File P.swift
>
> protocol/struct/class P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
>
> Same or other file
>
> struct S: P {
>
> override func m() { print("S.m") } // Note override required
> because m already has an implementation from the extension
>
>
> Requiring `override` breaks retroactive conformance of types to protocols.
> This idea has been brought up over half a dozen times. Each time it fails
> in not being able to accommodate retroactive conformance.
>
>
> }
>
> val p: P = S() // Note typed as P
>
> p.m() // Now prints S.m as expected
>
>
> Extensions in the same file as the declaration can have any access, can be
> final, and can have where clauses and provide inheritable implementations.
>
>
> The implementation needed to achieve this is that a value instance typed
> as a protocol is copied onto the heap, a pointer to its Vtable added, and
> it is passed as a pointer. IE it becomes a class instance. No change needed
> for a class instance typed as a protocol.
>
>
> The second use case is adding static functions.
>
>
> A new type of extension is proposed, a static final extension, which can
> be either in or outside the file in which the protocol/struct/class
> declaration is in. EG:
>
>
> static final extension P { // Note extension marked static final
>
> func m() { print("P.m") }
>
> }
>
>
> Which is called as any other static function would be called:
>
>
> val s = S()
>
> P.m(s) // Prints P.m as expected
>
>
> The new static final extension is shorthand, particularly in the case of
> multiple functions, for:
>
>
> extension P {
>
> static final func m(_ this: P) { print("P.m") }
>
> }
>
>
> If the static final extension is outside of the file in which the
> protocol/struct/class declaration is in then the extension and the methods
> can only have fileprivate and internal access.
>
>
> What is the use case for having this restriction? What is the problem you
> are trying to solve?
>
>
>
> As at present protocol/struct/class can have both a static and instance
> method of the same name, m in the case of the example, because the usage
> syntax is distinct. As at present, static final extensions, both the
> extension and the individual functions, can have where clauses.
>
>
> In summary.
>
>
> The proposal formalises the split use of extensions into their two uses:
> implementing methods and adding static functions. Syntax is added that
> clarifies both for declarations and usage which type of extension is
> provided/in use.
>
>
> Note the distinction between an extension in the same file and in a
> separate file is consistent with the proposed use of private in
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> .
>
> Comments?
>
> -- Howard.
>
> On 7 Apr 2017, at 4:49 am, Jordan Rose  wrote:
>
> [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md
> ]
>
> On Apr 

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]

@Xiaodi,

You make two drugs. 

1. Deliberately making retroactive conformance outside of the file in which the 
type is declared illegal because of the problems it causes. See all the 
questions on Swift Users and watch people learning Swift get caught out. 

2. Outside of the file in which the type is declared the static final extension 
is restricted to internal or fileprivate so that multiple modules can add 
static final extensions without clashes. 

-- Howard. 

> On 11 Apr 2017, at 8:51 am, Xiaodi Wu  wrote:
> 
>> On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution 
>>  wrote:
>> In response to Jordan Rose's comment I suggest the following change:
>> 
>> Proposal: Split extension usage up into implementing methods and adding 
>> static functions
>> 
>> Currently extension methods are confusing because they have different 
>> dispatch rules for the same syntax. EG:
>> 
>> protocol P {
>> func m()
>> }
>> extension P {
>> func m() { print("P.m") }
>> }
>> struct S: P {
>> func m() { print("S.m") }
>> }
>> val p: P = S() // Note typed as P
>> p.m() // Surprisingly prints P.m even though S implements its own m
> 
> This is incorrect. This prints "S.m", not "P.m".
>  
>> val s = S() // Note typed as S
>> s.m() // Prints S.m as expected 
>> 
>> This proposal cures the above problem by separating extension methods into 
>> two seperate use cases: implementations for methods and adding static 
>> functions. 
>> 
>> First implementing methods.
>> 
>> If the extension is in the same file as the protocol/struct/class 
>> declaration then it implements the methods and is dispatched using a Vtable. 
>> EG:
>> 
>> File P.swift
>> protocol/struct/class P {
>> func m()
>> }
>> extension P {
>> func m() { print("P.m") }
>> }
>> 
>> Same or other file
>> struct S: P {
>> override func m() { print("S.m") } // Note override required because 
>> m already has an implementation from the extension
> 
> Requiring `override` breaks retroactive conformance of types to protocols. 
> This idea has been brought up over half a dozen times. Each time it fails in 
> not being able to accommodate retroactive conformance.
>  
>> }
>> val p: P = S() // Note typed as P
>> p.m() // Now prints S.m as expected 
>> 
>> Extensions in the same file as the declaration can have any access, can be 
>> final, and can have where clauses and provide inheritable implementations. 
>> 
>> The implementation needed to achieve this is that a value instance typed as 
>> a protocol is copied onto the heap, a pointer to its Vtable added, and it is 
>> passed as a pointer. IE it becomes a class instance. No change needed for a 
>> class instance typed as a protocol. 
>> 
>> The second use case is adding static functions.
>> 
>> A new type of extension is proposed, a static final extension, which can be 
>> either in or outside the file in which the protocol/struct/class declaration 
>> is in. EG:
>> 
>> static final extension P { // Note extension marked static final
>> func m() { print("P.m") }
>> }
>> 
>> Which is called as any other static function would be called:
>> 
>> val s = S()
>> P.m(s) // Prints P.m as expected
>> 
>> The new static final extension is shorthand, particularly in the case of 
>> multiple functions, for:
>> 
>> extension P {
>> static final func m(_ this: P) { print("P.m") }
>> }
>> 
>> If the static final extension is outside of the file in which the 
>> protocol/struct/class declaration is in then the extension and the methods 
>> can only have fileprivate and internal access.
> 
> What is the use case for having this restriction? What is the problem you are 
> trying to solve? 
> 
>  
>> 
>> As at present protocol/struct/class can have both a static and instance 
>> method of the same name, m in the case of the example, because the usage 
>> syntax is distinct. As at present, static final extensions, both the 
>> extension and the individual functions, can have where clauses.
>> 
>> In summary.
>> 
>> The proposal formalises the split use of extensions into their two uses: 
>> implementing methods and adding static functions. Syntax is added that 
>> clarifies both for declarations and usage which type of extension is 
>> provided/in use.
>> 
>> Note the distinction between an extension in the same file and in a separate 
>> file is consistent with the proposed use of private in 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md.
>> 
>> Comments?
>> 
>> -- Howard.
>> 
>>> On 7 Apr 2017, at 4:49 am, Jordan Rose  wrote:
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md]
>>> 
> On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution 
>  wrote:
> 
> The review of SE

[swift-evolution] SE-0169

[Michael Mayer via swift-evolution]

All -

I am not in favor of this change.  While I agree that the implementation of 
fileprivate and open as well as the changes to private had some unintended 
by-products, they can easily be accommodated.  Sometimes the language by its 
nature dictates style.  I say at this point, we all just need to deal with it 
and move on.  We have bigger and more impactful language features to fry.  

IMHO the changes in this proposal create a host of complications in the 
understanding of what can already be a hard to understand topic.  We are 
greatly increasing the surface area of what must be learned in order to 
completely grok private and fileprivate.  This added complexity does not 
justify what I feel are just cosmetic improvements to suit a particular coding 
style.  

Changes such as this to suit a particular coding style, need to be avoided or 
we risk losing focus on the definition and implementation of more critical 
changes.

I don’t comment on many proposals, but this one stood out as antithetical to 
the stated goals of the Swift evolution.

Regards, Michael

==
Michael M. Mayer
Hanover, MD
m.may...@gmail.com

___
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

[Hooman Mehr via swift-evolution]

+0.5 

Positive on multi-line string literal
Negative on the delimiter.

I don’t like continuation character, but would like to have something similar 
to classic C comments: distinct, symmetrical opening and closing delimiters. 
But I don’t have any specific suggestion.


> On Apr 7, 2017, at 11:32 AM, Peter Dillinger via swift-evolution 
>  wrote:
> 
> • What is your evaluation of the proposal?
>  
> -1, for two reasons:
>  
> (from 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html
>  
> 
>  and follow-up)
> First, having the same beginning and ending delimiter, with no continuation 
> character, makes it very easy for a syntax highlighter or tokenizer to get 
> "inverted" in what it believes is string content and what it believes is 
> code.  I have seen this happen due to a subtle bug in a Python syntax 
> highlighter, and it's incredibly frustrating that a single misinterpretation 
> can "invert" the highlighting of the rest of the file.  It's also possible 
> that future syntactic enhancements to Swift could lead to inversion in a 
> correct highlighter for an older version of Swift reading a newer Swift file.
>  
> When working with an online tokenizer / highlighter while editing your code, 
> the proposed design maximizes what needs to get re-parsed as """ are added 
> and removed.  Sure, automatic insertion of close-""" helps, but not fully.
>  
> Under this proposal, you might say, "you can assume it's code again if the 
> indentation decreases too much."  There are two problems with that.  First, 
> the required indentation is determined by the line with the close """, so 
> there's no way to detect a violation until you get there.  Second, the user 
> might have intended that as part of the quoted text but messed up the 
> formatting.  In that case, if you assume resumption of code, the actual close 
> """ will be interpreted as an open """ and you have inversion anyway.  So 
> it's not clear that you've decreased the likelihood of inversion.
>  
>  
> Second, as others have pointed out, the proposal is quite lacking in 
> specifics.  For example, it's not clear if characters are allowed on the same 
> line after an open """.  If not allowed, a syntax highlighter could 
> heuristically distinguish open and close """ based on non-whitespace on the 
> same line (just not the case of """ on a line with only whitespace - perhaps 
> that should be disallowed).  This could be helpful for recovery in 
> tokenization/highlighting, but this proposal is unclear.
>  
>  
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
>  
> Yes.  Especially since unused string expressions are not a compilation error, 
> using + to construct long strings spanning multiple lines is hazardous.
> (See 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034472.html
>  
> 
>  )
>  
>  
> • Does this proposal fit well with the feel and direction of Swift?
>  
> I'm not satisfied this proposal has sufficiently addressed issues in the 
> language feature being mostly inherited here.
>  
>  
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>  
> I have experience with some tools supporting Python and we had issues with 
> syntax highlighting ending up "inverted" because """ strings have the same 
> beginning and ending delimiter.
>  
>  
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>  
> A quick read, and participation in the discussion.  I don't see any evidence 
> the proposal took into account recent discussion:
>  
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034856.html
>  
> 
>  
> -- 
> Peter Dillinger, Ph.D.
> Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
> Synopsys
> www.synopsys.com/software 
>  
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

[Hooman Mehr via swift-evolution]

+1 with this clarification / revision

> On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Apr 5, 2017, at 10:32 PM, Félix Cloutier > > wrote:
>> 
>> During the proposal phase, we asked how this would handle fixed-length 
>> strings with an optional NUL terminator. For instance, in a C `struct Foo { 
>> char name[8]; };`, `name` stops at the first \0, or at the eighth byte, 
>> whichever comes first. IIRC, Ben said that it would be handled, but I'd like 
>> to have it clarified.
>> 
>> Is it correct to assume that a UnicodeEncoding is expected to return 
>> UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping 
>> before the end of the buffer if necessary)? Is it also correct to assume 
>> that if you need this functionality, you'll be looking at code like this?
>> 
>> var result = ""
>> UnicodeEncoding.parseForward(bufferPointer) { result += $0 }
>> 
> 
> 
> Hi Félix,
> 
> Having talked about it among the team, it feels like we should add an 
> initializer from a Collection of code units to this proposal.  Therefore 
> given a pointer p to some utf8 and a length n, you would write:
> 
> let b = UnsafeBuffer(start: p, count: n)
> // naming opinions on the argument labels welcomed, this is probably what I’d 
> go for...
> let s = String(b, fromEncoding: UTF8.self)
> 
> Similar to the C string inits, this would only be a repairing initializer.
> 
> Your request goes a little bit further though. For that, I would say that it 
> probably doesn’t deserve a special dedicated initializer. You could instead 
> search for the nil using index(of:):
> 
> let i = b.index(of: 0)
> let s = String(b[.. 
> Does this sound reasonable?
> 
>>> Le 5 avr. 2017 à 11:39, John McCall via swift-evolution 
>>> mailto:swift-evolution@swift.org>> a écrit :
>>> 
>>> Hello, Swift community!
>>> 
>>> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
>>> Transcoding" begins now and runs through next Tuesday, April 11th. The 
>>> proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.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/0155-normalize-enum-case-representation.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,
>>> 
>>> John McCall
>>> Review Manager
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Hooman Mehr via swift-evolution]

+1 

Having the feature is worth the oddities of the syntax.

> On Apr 5, 2017, at 4:01 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>  
> 
> 
> Hello Swift community,
> 
> The review of SE-0161 “Smart KeyPaths: Better Key-Value Coding for Swift” ran 
> from March 30...April 5, 2017. The proposal was very well-received *except* 
> that reviewers felt that the #keyPath syntax was far too heavy for this new 
> language construct, and preferred the lighter-weight syntax of the pre-review 
> drafts. This proposal is returned for revision to address the syntax.
> 
> The heavyweight #keyPath syntax was requested by the core team after 
> reviewing earlier drafts, which used a far lighter syntax:
> 
>   // (Rejected) syntax from pre-review drafts
>   let firstFriendsNameKeyPath = Person.friends[0].name
>   print(luke[keyPath: .friends[0].name])
> 
> The core team’s specific concern was that these key path expressions (e.g., 
> Person.friends[0].name) don’t make it sufficiently clear that the actual 
> property accesses are being delayed, and that the contextual cues (“Person." 
> vs. “luke.”) are insufficient to disambiguate for the human reader. Hence, 
> the request for a different (more explicit) syntax.
> 
> Reviewers rightly point out that it is natural for key-paths to use the same 
> syntax as unapplied instance method references, e.g., 
> Person.someInstanceMethod produces a value of some function type with the 
> “Self” type curried, e.g., (Person) -> (param-types) -> result-type. The core 
> team agrees with this sentiment. The core team also felt that Swift’s 
> existing unapplied method references suffer from the same clarity problems as 
> the initial key-path syntax, i.e., that it isn’t sufficiently clear that the 
> actual application of “self” is being delayed.
> 
> The core team has a specific proposal: use the backslash (‘\’) to as a 
> leading indicator for key paths. Specifically,
> 
>   // Proposed syntax for second revision
>   let firstFriendsNameKeyPath = \Person.friends[0].name
>   print(luke[keyPath: \.friends[0].name])
> 
> The backslash is a visual cue that the actual application of this chain of 
> property references is delayed, eliminating ambiguities, yet is still quite 
> lightweight and feels “first-class” in the language.
> 
> The core team felt that, in the future, the backslash should also be used for 
> unapplied instance method references, to match the proposed syntax for key 
> paths and improve clarity for this non obvious feature. This change could be 
> staged in as a revision to the accepted-but-never-implemented SE-0042: 
> Flattening the function type of unapplied method references 
> ,
>  e.g.,
> 
>   // Proposed future syntax for unapplied instance method references
> class Person {
> func instanceMethod(_: String) -> Int { … }
>   }
> 
>   let f1 = Person.instanceMethod   // to-be-deprecated; produces a value 
> of type (Person) -> (String) -> Int
>   let f2 = \Person.instanceMethod  // to-be-introduced via a revised 
> SE-0042: produces a value of type (Person, String) -> Int
> 
> Such an approach gives us a way to stage in SE-0042 and get to eventual 
> consistency between key paths and unapplied instance method references.
> 
>   - 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

Re: [swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

[Hooman Mehr via swift-evolution]

Agreed. +1

> On Apr 6, 2017, at 11:51 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md
>  
> ]
> 
> +1 from me, for all the reasons in the proposal. 'final' doesn't mean 
> anything in protocol extensions right now—it is literally ignored—so 
> regardless of the actual justified confusion around extension members that 
> satisfy requirements and those that don't, we should go forward with removing 
> 'final'.
> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Rex Fenley via swift-evolution]

How exactly does that work from the perspective of the initializer if you
have 2 sets of keys to choose from? Would I extend the initializer to
include my feature flag `public init(from decoder: Decoder, flag: Bool)
throws` and switch on that? Or could I pass in the Container I want to use
somehow, which seems cleaner to me as an abstraction? (This is similar to
what we're already doing with the setup we have.) How does a key jump
multiple levels "permissions.can_send_message" and is there a way to know
ahead of time which key maps to what property? Needing to express every
possible mapping from the initializer seems clumsy to me and I think would
fit better as a part of the Container itself.

On Mon, Apr 10, 2017 at 3:13 PM, Tony Parker 
wrote:

> Hi Rex,
>
> On Apr 10, 2017, at 12:48 PM, Rex Fenley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Forgive me if I'm missing something, this is a very large proposal and a
> lot to parse through. I like how everything is designed as far as I can
> tell except I'm not sure from this proposal how one would compose multiple
> different types of Decoders against the same output type. For example, with
> Location we have.
>
> // Continuing examples from before; below is automatically generated by
> the compiler if no customization is needed.
> public struct Location : Codable {
> private enum CodingKeys : CodingKey {
> case latitude
> case longitude
> }
>
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> latitude = try container.decode(Double.self, forKey: .latitude)
> longitude = try container.decode(Double.self, forKey: .longitude)
> }
> }
>
> However, this initializer seems strictly tied to the `CodingKeys` set of
> coding keys. From what it appears, if this was used to decode from JSON the
> format would have to always be:
>
> {
> "latitude" : 20.0
> "longitude" : 20.0
> }
>
> I have a use case we're on my client we began the process of switching
> from one version of an API to another. In one version we had a payload
> similar to
>
> {
> "user" : {
> "uuid" : "uuid string..."
> "can_send_message" : true
> "can_delete_message" : false
> }
> }
>
> this would result in the following Codable (from "user") from what I'm
> following
>
> public struct User : Codable {
> private enum CodingKeys : CodingKey {
> case uuid
> case can_send_message
> case can_delete_message
> }
>
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> uuid = try container.decode(Double.self, forKey: .uuid)
> canSendMessage = try container.decode(Bool.self, forKey:
> .can_send_message)
> canDeleteMessage = try container.decode(Bool.self, forKey:
> .can_delete_message)
> }
> }
>
> when we began switching over to the new api the payload was returned as
>
> {
> user {
> "uuid" : "uuid string..."
> "permissions" : {
> "can_send_message" : true
> "can_delete_message" : false
> }
> }
> }
>
> Here with "permissions" we have a new internal container with a separate
> set of coding keys. Issue is in my use case I still need to maintain a way
> to decode the old version simultaneously; we guard all new changes behind
> feature flags in case something goes awry and we need to roll back our
> changes.
>
> How would one go about expressing this new Decoding and the previous
> Decoding simultaneously on the same User type?
>
>
> You would fall out of the automatically-generated scenario here, but this
> use case is exactly what the ‘container’ API is for. You can create a
> container with a new set of keys, then decode from it.
>
> Another approach would be to create a nested type that conforms with
> Codable which represents the “permissions” as a type of its own.
>
> - Tony
>
>
>
> --
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com  |  BLOG   |
>  FOLLOW US   |  LIKE US
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Ricardo Parada via swift-evolution]

I have not voted in favor or against the proposal. I have been reading a lot of 
responses but I agree with Tony. 

When I started reading the proposal everything was more or less fine half way 
through the proposal because it was reverting private to fileprivate between 
the type and its extensions within the same file. I said, if you think of the 
type and its extensions as a unit then it makes sense. I can explain that. 

Then it started describing a different behavior among the extensions located in 
a file separate from the file containing the definition of the type. That just 
started a whole debate inside my head and I understand the passionate responses 
on both sides. 

But then I imagined myself explaining this to someone new to Swift and it just 
doesn't seem right. If it becomes convoluted then that's a red flag that it 
does not belong in Swift. 

I agree fileprivate may be ugly to some and it may be more popular than 
private. But I think fileprivate is very clear. I know what it does from its 
name without having to ask. And private behaves the way private works in other 
languages. 

Regards


> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
>>> But even outside the generated code use cases, it's nice to just be able to 
>>> implement helpers or additional "convenience" conformances in separate 
>>> files named appropriately (like "Type+Protocol.swift" or 
>>> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>> 
>> No doubt about the usefulness of having separate files with extensions here
>> 
>>> If nothing else, nested extensions could save those who actually don't care 
>>> much about such issues from another breaking change in Swift — and imho it 
>>> adds consistency:
>>> We can nest types, so why can't we nest extensions?
>>> 
>>> Because types and extensions are quite different beasts, so something that 
>>> applies to one doesn't necessarily apply to the other.
>> 
>> I don't buy this argument at all without an objective explanation why the 
>> curly braces of extensions should be treated different than the curly braces 
>> of types...
> 
> They shouldn't be. That's why I don't support SE-0169 either, because it 
> would allow extensions to extend the *scope* rather than the *type*, but only 
> within the same file. I think that's fundamentally broken.
> 
> But my comment wasn't about curly braces—it was about types vs. extensions. 
> For example, you can declare local types within a function, but you can't 
> extend a type within a function (nor do I think it would be a good idea).
> 
>  
>> 
>>> I don't think that holds its weight. This feels like another case of "let's 
>>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>>> changing a completely different feature to make things fall into place", 
>>> which I don't think is a sound motivation or design principle. The example 
>>> you posted in your initial message weaves multiple types/nesting levels 
>>> together in a way that looks *incredibly* difficult to follow/parse to even 
>>> an experienced user of the language.
>> 
>> Did you noticed that I started this example as mockery? In real life, I 
>> would hopefully never nest more than once… and do you think sprinkling parts 
>> of class over the project is easier to follow?
> 
> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* parts 
> of a type across the project, but if there's some kind of "aside" 
> functionality that doesn't depend on private knowledge of the type, then I 
> find it to be a nice feature to have. It requires me to have reasonable names 
> to my source files, but that's not a significant burden.
> 
>  
>> 
>>> Everyone seems to be striving for a "perfect" level of access control that 
>>> lets individual types/members dictate precisely what other types/members 
>>> can access them. I'm not sure if that perfection is attainable or not, but 
>>> even if it is, I don't think it's something we should strive for. I'd 
>>> rather have a simple visibility model that leaks a little than an air-tight 
>>> model that allows people to write overly complicated code for the sake of 
>>> fine-tuning access.
>> 
>> I had no desire to change the model of Swift 2 — but apparently, others 
>> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
>> model like nesting over a complicated one with less power.
>> 
>>> Let's remember that the core team has limited resources to implement the 
>>> things we propose, and if I have to choose between, say, serialization, 
>>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>>> again, it's clear to me which one I would want dropped on the floor. I 
>>> don't want perfect to be the enemy of good.
>> 
>> Well, right now, there are several (at least one ;-) proposals that aim for 
>> a breaking change of the whole model…

[swift-evolution] [Pitch] Remove type-inference for stored property

[David Beck via swift-evolution]

This seems like something a linter should handle.

> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> 
> 
>  


David Beck
http://davidbeck.co
http://twitter.com/davbeck
http://facebook.com/davbeck

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

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[David Beck via swift-evolution]

> Hello Swift community,
> 
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.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/0167-swift-encoders.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?

2 big thumbs up. 👍🏽👍🏽

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

Yes.

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

Yes.

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

Ruby’s multiline string literals are much more flexible (and varied). In 
theory, being able to provide your own delimiter makes sense (what if I need to 
type 3 quotes in my multiline string?!?!) but in practice just adds confusion, 
especially for beginners. Looking at code examples, it’s not obvious where the 
string literal ends. It also isn’t directly connected to regular string 
literals either.

ES2015 uses a similar approach as here, using back-ticks instead of triple 
quotes. That makes sense there, where they also use them for single line 
pattern strings, but again isn’t directly connected to other string literal 
syntax.

ObjCs strings have the benefit of controlling indentation much more 
predictably. If there’s anything I’m concerned about here, it’s that. But I 
don’t think that’s a high enough priority to sacrifice the other benefits of 
the proposed syntax. I would be happy to see that syntax added as an additive 
alternative in a future proposal (something like “line 1”\”line 2”).

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

a quick reading

> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe
> Review Manager
> 
> 
>  


David Beck
http://davidbeck.co
http://twitter.com/davbeck
http://facebook.com/davbeck

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

[swift-evolution] SE-165: Dictionary & Set Enhancements

[David Beck via swift-evolution]

> Hello, Swift community!
> 
> The review of "SE-165: Dictionary&Set Enhancements" begins now and runs 
> through next Tuesday, April 11th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.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/0165-dict.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?

This looks great! I’ve definitely written a few of these methods myself, and if 
they were available in the standard library, I’d probably reach for them more 
often instead of less elegant solutions.

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

The language could survive without these changes, but if made, would prove 
useful.

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

Yes.

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

Ruby has a lot of these kinds of tools and they have been useful.

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

a quick reading

> 
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> Ben Cohen
> Review Manager
> 
> 
> 
> 
>  


David Beck
http://davidbeck.co
http://twitter.com/davbeck
http://facebook.com/davbeck

___
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]

On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> In response to Jordan Rose's comment I suggest the following change:
>
> Proposal: Split extension usage up into implementing methods and adding
> static functions
>
>
> Currently extension methods are confusing because they have different
> dispatch rules for the same syntax. EG:
>
>
> protocol P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
> struct S: P {
>
> func m() { print("S.m") }
>
> }
>
> val p: P = S() // Note typed as P
>
> p.m() // Surprisingly prints P.m even though S implements its own m
>

This is incorrect. This prints "S.m", not "P.m".


> val s = S() // Note typed as S
>
> s.m() // Prints S.m as expected
>
>
> This proposal cures the above problem by separating extension methods into
> two seperate use cases: implementations for methods and adding static
> functions.
>
>
> First implementing methods.
>
>
> If the extension is in the same file as the protocol/struct/class
> declaration then it implements the methods and is dispatched using a
> Vtable. EG:
>
>
> File P.swift
>
> protocol/struct/class P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
>
> Same or other file
>
> struct S: P {
>
> override func m() { print("S.m") } // Note override required
> because m already has an implementation from the extension
>

Requiring `override` breaks retroactive conformance of types to protocols.
This idea has been brought up over half a dozen times. Each time it fails
in not being able to accommodate retroactive conformance.


> }
>
> val p: P = S() // Note typed as P
>
> p.m() // Now prints S.m as expected
>
>
> Extensions in the same file as the declaration can have any access, can be
> final, and can have where clauses and provide inheritable implementations.
>
>
> The implementation needed to achieve this is that a value instance typed
> as a protocol is copied onto the heap, a pointer to its Vtable added, and
> it is passed as a pointer. IE it becomes a class instance. No change needed
> for a class instance typed as a protocol.
>
>
> The second use case is adding static functions.
>
>
> A new type of extension is proposed, a static final extension, which can
> be either in or outside the file in which the protocol/struct/class
> declaration is in. EG:
>
>
> static final extension P { // Note extension marked static final
>
> func m() { print("P.m") }
>
> }
>
>
> Which is called as any other static function would be called:
>
>
> val s = S()
>
> P.m(s) // Prints P.m as expected
>
>
> The new static final extension is shorthand, particularly in the case of
> multiple functions, for:
>
>
> extension P {
>
> static final func m(_ this: P) { print("P.m") }
>
> }
>
>
> If the static final extension is outside of the file in which the
> protocol/struct/class declaration is in then the extension and the methods
> can only have fileprivate and internal access.
>

What is the use case for having this restriction? What is the problem you
are trying to solve?



> As at present protocol/struct/class can have both a static and instance
> method of the same name, m in the case of the example, because the usage
> syntax is distinct. As at present, static final extensions, both the
> extension and the individual functions, can have where clauses.
>
>
> In summary.
>
>
> The proposal formalises the split use of extensions into their two uses:
> implementing methods and adding static functions. Syntax is added that
> clarifies both for declarations and usage which type of extension is
> provided/in use.
>
>
> Note the distinction between an extension in the same file and in a
> separate file is consistent with the proposed use of private in
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0169-improve-interaction-between-private-
> declarations-and-extensions.md.
>
> Comments?
>
> -- Howard.
>
> On 7 Apr 2017, at 4:49 am, Jordan Rose  wrote:
>
> [Proposal: https://github.com/apple/swift-evolution/blob/
> master/proposals/0164-remove-final-support-in-protocol-extensions.md]
>
> On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The review of SE-0164 "Remove final support in protocol extensions"
>
>
>- What is your evaluation of the proposal?
>
> The present situation isn't great. People get confused about which method
> will called with protocol extensions. Seems like every week there is a
> variation on this confusion on Swift Users mailing list. Therefore
> something needs to be done.
>
> However I am not keen on this proposal since it makes behaviour
> inconsistent between methods in protocol extensions, classes, and structs.
>
> I think a better solution would be one of the following alternatives:
>
>   1. Must u

[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]

In response to Jordan Rose's comment I suggest the following change:

Proposal: Split extension usage up into implementing methods and adding static 
functions

Currently extension methods are confusing because they have different dispatch 
rules for the same syntax. EG:

protocol P {
func m()
}
extension P {
func m() { print("P.m") }
}
struct S: P {
func m() { print("S.m") }
}
val p: P = S() // Note typed as P
p.m() // Surprisingly prints P.m even though S implements its own m
val s = S() // Note typed as S
s.m() // Prints S.m as expected 

This proposal cures the above problem by separating extension methods into two 
seperate use cases: implementations for methods and adding static functions. 

First implementing methods.

If the extension is in the same file as the protocol/struct/class declaration 
then it implements the methods and is dispatched using a Vtable. EG:

File P.swift
protocol/struct/class P {
func m()
}
extension P {
func m() { print("P.m") }
}

Same or other file
struct S: P {
override func m() { print("S.m") } // Note override required because m 
already has an implementation from the extension
}
val p: P = S() // Note typed as P
p.m() // Now prints S.m as expected 

Extensions in the same file as the declaration can have any access, can be 
final, and can have where clauses and provide inheritable implementations. 

The implementation needed to achieve this is that a value instance typed as a 
protocol is copied onto the heap, a pointer to its Vtable added, and it is 
passed as a pointer. IE it becomes a class instance. No change needed for a 
class instance typed as a protocol. 

The second use case is adding static functions.

A new type of extension is proposed, a static final extension, which can be 
either in or outside the file in which the protocol/struct/class declaration is 
in. EG:

static final extension P { // Note extension marked static final
func m() { print("P.m") }
}

Which is called as any other static function would be called:

val s = S()
P.m(s) // Prints P.m as expected

The new static final extension is shorthand, particularly in the case of 
multiple functions, for:

extension P {
static final func m(_ this: P) { print("P.m") }
}

If the static final extension is outside of the file in which the 
protocol/struct/class declaration is in then the extension and the methods can 
only have fileprivate and internal access.

As at present protocol/struct/class can have both a static and instance method 
of the same name, m in the case of the example, because the usage syntax is 
distinct. As at present, static final extensions, both the extension and the 
individual functions, can have where clauses.

In summary.

The proposal formalises the split use of extensions into their two uses: 
implementing methods and adding static functions. Syntax is added that 
clarifies both for declarations and usage which type of extension is 
provided/in use.

Note the distinction between an extension in the same file and in a separate 
file is consistent with the proposed use of private in 
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md.

Comments?

-- Howard.

> On 7 Apr 2017, at 4:49 am, Jordan Rose  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md]
> 
>>> On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution 
>>>  wrote:
>>> 
>>> The review of SE-0164 "Remove final support in protocol extensions"
>>> 
>> 
>>> What is your evaluation of the proposal?
>> The present situation isn't great. People get confused about which method 
>> will called with protocol extensions. Seems like every week there is a 
>> variation on this confusion on Swift Users mailing list. Therefore something 
>> needs to be done. 
>> 
>> However I am not keen on this proposal since it makes behaviour inconsistent 
>> between methods in protocol extensions, classes, and structs. 
>> 
>> I think a better solution would be one of the following alternatives:
>> 
>>   1. Must use final and final means it cannot be overridden; or
>>   2. If not final dispatches using a table like a class and if marked final 
>> cannot be overridden and if marked dynamic uses obj-c dispatching; or
>>   3. Must be marked dynamic and uses obj-c dispatching. 
>> 
>> My preference would be option 2 but I think any of the three is superior to 
>> the present situation or the proposal. 
> 
> People have suggested all of these before, but none of them are obviously 
> correct. It's true that we have a difference between extension members that 
> satisfy requirements and those that don't, and that that confuses people. 
> However, an extension-only member of one protocol can be used to satisfy the 
> requ

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Colin Barrett via swift-evolution]

Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md

I'm a +1 on the proposal, I just have a few small questions and suggestions
after giving it a brief read.

1) I'm not thrilled about the name "unkeyedContainer()" and related names.
Would "sequentialContainer" or something along those lines be a better
name? The fact that it can encode several, heterogeneous values in a fixed
sequence seems to be the most salient feature of it that distinguishes it
from the keyed containers and the single value containers.

2) I feel like the reasoning behind the design for the CodingUserInfoKey
isn't clearly articulated, but it seems a bit odd to me. First off, I'm
confused why with the current design, the declaration isn't simply:

protocol CodingUserInfoKey: CodingKey, Hashable {}

I tried mocking something up with the shipping Swift 3.1, and got the
following error:

> using 'CodingUserInfoKey' as a concrete type conforming to protocol
'Hashable' is not supported

So maybe it's just a question of lack of compiler support. Still, I feel
that the lack of a connection between the CodingKey and the
CodingUserInfoKey types is fairly confusing.

To be more concrete but way more speculative, I'm assuming that current
design one is intended to declare all their keys in an enum like,

enum SomeType.Key: CodingKey {
  case foo
  case bar
  // ...
  case metaKey1
  case metaKey2
}

And then write an init? extension for CodingUserInfoKey.

It seems more natural however to me to leverage the nested container
support instead. What exactly that design would look like is unclear to
me—do you return a value that implements Encoder? Do you add duplicate
nestedKeyedEncoder for the userInfo case? but it seems more of a clean fit
with the rest of the API than exposing a dictionary.

Both pretty minor issues when considered with all the great ideas in the
API. Looking forward to reviewing 0167 as well!

Cheers,
-C

On Thu, Apr 6, 2017 at 2:10 PM Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs
> through April 12, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Tony Parker via swift-evolution]

Hi Rex,

> On Apr 10, 2017, at 12:48 PM, Rex Fenley via swift-evolution 
>  wrote:
> 
> Forgive me if I'm missing something, this is a very large proposal and a lot 
> to parse through. I like how everything is designed as far as I can tell 
> except I'm not sure from this proposal how one would compose multiple 
> different types of Decoders against the same output type. For example, with 
> Location we have.
> 
> // Continuing examples from before; below is automatically generated by the 
> compiler if no customization is needed.
> public struct Location : Codable {
>   private enum CodingKeys : CodingKey {
> case latitude
> case longitude
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> latitude = try container.decode(Double.self, forKey: .latitude)
> longitude = try container.decode(Double.self, forKey: .longitude)
> }
> }
> 
> However, this initializer seems strictly tied to the `CodingKeys` set of 
> coding keys. From what it appears, if this was used to decode from JSON the 
> format would have to always be:
> 
> {
>   "latitude" : 20.0
>   "longitude" : 20.0
> }
> 
> I have a use case we're on my client we began the process of switching from 
> one version of an API to another. In one version we had a payload similar to
> 
> {
>   "user" : {
>   "uuid" : "uuid string..."
>   "can_send_message" : true
>   "can_delete_message" : false
>   }
> }
> 
> this would result in the following Codable (from "user") from what I'm 
> following
> 
> public struct User : Codable {
>   private enum CodingKeys : CodingKey {
> case uuid
> case can_send_message
> case can_delete_message
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> uuid = try container.decode(Double.self, forKey: .uuid)
> canSendMessage = try container.decode(Bool.self, forKey: 
> .can_send_message)
> canDeleteMessage = try container.decode(Bool.self, forKey: 
> .can_delete_message)
> }
> }
> 
> when we began switching over to the new api the payload was returned as
> 
> {
>   user {
>   "uuid" : "uuid string..."
>   "permissions" : {
>   "can_send_message" : true
>   "can_delete_message" : false
>   }
>   }
> }
> 
> Here with "permissions" we have a new internal container with a separate set 
> of coding keys. Issue is in my use case I still need to maintain a way to 
> decode the old version simultaneously; we guard all new changes behind 
> feature flags in case something goes awry and we need to roll back our 
> changes.
> 
> How would one go about expressing this new Decoding and the previous Decoding 
> simultaneously on the same User type?

You would fall out of the automatically-generated scenario here, but this use 
case is exactly what the ‘container’ API is for. You can create a container 
with a new set of keys, then decode from it.

Another approach would be to create a nested type that conforms with Codable 
which represents the “permissions” as a type of its own.

- Tony

> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> 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-0167: Swift Encoders

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
 
]

There's some pretty cool stuff in here. Nice work. I do have a few questions 
about this design, though:

- Why are the encoders and decoders open classes? (In particular, the fixed set 
of "strategies" seems like it'll be a problem if we plan to keep adding cases.) 
For that matter, why make them classes at all?

- I don't understand 'DateEncodingStrategy.deferredToDate'. It seems like this 
will always match one of the other cases in practice, and it isn't safe for any 
stable encoding.

- I assume you've thought about this, but there's no way for existing Cocoa 
types to conform to Decodable, since it introduces a new required initializer.* 
The design here doesn't rely on that at all, but I feel like it's worth calling 
out explicitly.


* Why does Decodable introduce a required initializer? Because when a class 
conforms to a protocol, it's declaring that it and all its subclasses conform 
to the protocol. But since initializers are not automatically inherited in 
Swift, there's no way to add new initializers to all existing subclasses.

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

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 3:47 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> This is a really great proposal. As an iOS developer I work with JSON 
>>> almost every day since most mobile apps communicate with a backend through 
>>> JSON messages. It's good to see that better JSON support is coming to 
>>> Foundation so we don't have to rely on third party libraries.
>>> 
>>> That being said, there is one thing I don't like which is that the JSON 
>>> encoding function returns Data and the decoding function takes Data.
>>> 
>>> It would be really great if the Foundation team could introduce a dedicated 
>>> type of JSON.
>>> There are several advantages of working with a dedicated type.
>>> - The underlying data is always valid JSON
>>> - You can extend this type in the future with helper methods for 
>>> manipulating JSON
>>> - It makes it explicit what you are dealing with
>>> 
>>> A good analogy is the URL type. You could represent an URL with a String or 
>>> Data type, but by introducing a dedicated type you have the full advantages 
>>> mentioned above. Data on the other hand is like a generic container which 
>>> you cannot easily extend with URL or JSON specific methods.
>>> 
>>> Having a dedicated JSON type is also one of the reasons third party 
>>> libraries like SwiftyJSON are so popular. It makes it super easy to 
>>> manipulate JSON structures. And sometimes developers like would like to 
>>> manipulate JSON directly.
>> 
>> I don’t think it would be a good thing to have this in Foundation. 
>> Foundation needs to push developers towards adopting best practices, and 
>> manipulating JSON directly instead of going through Codable’s strong-typing 
>> is not necessarily recommended. I’m not saying it doesn’t have its uses. But 
>> it’s usefulness is definitely narrow now once we have Codable. I think this 
>> is something that should stay in a third-party library.
> 
> I haven't thought heavily about this, but the thoughts that I have say that 
> JSON just isn't a good type in Swift. It's not an efficient in-memory 
> representation and it's not a convenient structural representation (because 
> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit 
> that sometimes you're handed some JSON and you want to extract a little bit 
> of information out of it without building a typed representation of the whole 
> thing, but that still seems like something that doesn't need to be the common 
> path.

I agree.  It seems orthogonal to this proposal to me.  It would be easy enough 
for a library to add a Codable JSON type on top of this proposal.  Foundation 
could even do that in the future if there was strong enough motivation for it.

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

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

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Jordan Rose via swift-evolution]

> On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
>  wrote:
> 
>> 
>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> This is a really great proposal. As an iOS developer I work with JSON almost 
>> every day since most mobile apps communicate with a backend through JSON 
>> messages. It's good to see that better JSON support is coming to Foundation 
>> so we don't have to rely on third party libraries.
>> 
>> That being said, there is one thing I don't like which is that the JSON 
>> encoding function returns Data and the decoding function takes Data.
>> 
>> It would be really great if the Foundation team could introduce a dedicated 
>> type of JSON.
>> There are several advantages of working with a dedicated type.
>> - The underlying data is always valid JSON
>> - You can extend this type in the future with helper methods for 
>> manipulating JSON
>> - It makes it explicit what you are dealing with
>> 
>> A good analogy is the URL type. You could represent an URL with a String or 
>> Data type, but by introducing a dedicated type you have the full advantages 
>> mentioned above. Data on the other hand is like a generic container which 
>> you cannot easily extend with URL or JSON specific methods.
>> 
>> Having a dedicated JSON type is also one of the reasons third party 
>> libraries like SwiftyJSON are so popular. It makes it super easy to 
>> manipulate JSON structures. And sometimes developers like would like to 
>> manipulate JSON directly.
> 
> I don’t think it would be a good thing to have this in Foundation. Foundation 
> needs to push developers towards adopting best practices, and manipulating 
> JSON directly instead of going through Codable’s strong-typing is not 
> necessarily recommended. I’m not saying it doesn’t have its uses. But it’s 
> usefulness is definitely narrow now once we have Codable. I think this is 
> something that should stay in a third-party library.

I haven't thought heavily about this, but the thoughts that I have say that 
JSON just isn't a good type in Swift. It's not an efficient in-memory 
representation and it's not a convenient structural representation (because of 
the use of either 'Any' or 'JSON' in the recursive position). I'll admit that 
sometimes you're handed some JSON and you want to extract a little bit of 
information out of it without building a typed representation of the whole 
thing, but that still seems like something that doesn't need to be the common 
path.

Jordan

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

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Rex Fenley via swift-evolution]

Forgive me if I'm missing something, this is a very large proposal and a
lot to parse through. I like how everything is designed as far as I can
tell except I'm not sure from this proposal how one would compose multiple
different types of Decoders against the same output type. For example, with
Location we have.

// Continuing examples from before; below is automatically generated by the
compiler if no customization is needed.
public struct Location : Codable {
private enum CodingKeys : CodingKey {
case latitude
case longitude
}

public init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
latitude = try container.decode(Double.self, forKey: .latitude)
longitude = try container.decode(Double.self, forKey: .longitude)
}
}

However, this initializer seems strictly tied to the `CodingKeys` set of
coding keys. From what it appears, if this was used to decode from JSON the
format would have to always be:

{
"latitude" : 20.0
"longitude" : 20.0
}

I have a use case we're on my client we began the process of switching from
one version of an API to another. In one version we had a payload similar to

{
"user" : {
"uuid" : "uuid string..."
"can_send_message" : true
"can_delete_message" : false
}
}

this would result in the following Codable (from "user") from what I'm
following

public struct User : Codable {
private enum CodingKeys : CodingKey {
case uuid
case can_send_message
case can_delete_message
}

public init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
uuid = try container.decode(Double.self, forKey: .uuid)
canSendMessage = try container.decode(Bool.self, forKey:
.can_send_message)
canDeleteMessage = try container.decode(Bool.self, forKey:
.can_delete_message)
}
}

when we began switching over to the new api the payload was returned as

{
user {
"uuid" : "uuid string..."
"permissions" : {
"can_send_message" : true
"can_delete_message" : false
}
}
}

Here with "permissions" we have a new internal container with a separate
set of coding keys. Issue is in my use case I still need to maintain a way
to decode the old version simultaneously; we guard all new changes behind
feature flags in case something goes awry and we need to roll back our
changes.

How would one go about expressing this new Decoding and the previous
Decoding simultaneously on the same User type?


-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

[Kevin Nattinger via swift-evolution]

array.remove(where: { $0 > 3 })
array.remove { $0 > 3 }

> On Apr 10, 2017, at 12:25 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> How about this:
>> 
>> array.removeEvery(3)
>> array.removeEvery{ $0 > 3 }
>> 
>> I think it preserves the meaning while it reads nicely. However "every" has 
>> no precedent in other functions, as far as I know.
> 
> Every has a very ambiguous meaning in English. It could be understood as 
> "every 3 values" as in 0, 3, 6, 9, etc...
> 
>> Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution 
>> mailto:swift-evolution@swift.org>>:
>> 
>>> 
 On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon >>> > wrote:
 
> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> +1. Perfect. Let's not bikeshed this and get it done!
 
 
 Sorry, I'm going to have to insist on bikeshedding.
 
 `equalTo:` is kind of ugly and has no precedent in the standard library. 
 Similar APIs seem to either leave the parameter unlabeled or use `of:` (as 
 in `index(of:)`). I think unlabeled is probably the right answer here.
 
>>> 
>>> I think removeAll(of:) works well for the equatable value version.
>>> 
>>> FWIW of all the ideas from the all thread, containsOnly(_:) for the 
>>> equatable value version works for me. It has a nice symmetry: contains(3) 
>>> vs containsOnly(3).
>>> 
 The main shortcoming I can see is that if you see:
 
array.removeAll(3)
 
>>> 
>>> Personally don’t feel good about an unlabelled version. It doesn’t read 
>>> right. Remove all three what?
>>> 
 You might think `3` is either an index or a count. But neither of those 
 actually make sense:
 
 * It can't be an index because then `All` would have no meaning. There's 
 only ever one thing at a given index. Besides, indices are almost always 
 marked with `at:` or another parameter label.
 * It can't be a count because `All` is already a count. What could "remove 
 all 3" possibly mean if the array doesn't happen to have three elements?
 
 And this is only a problem if the value happens to be an integer. If it's 
 anything else, the type makes clear that this can't possibly be an index 
 or count; it must be an element.
 
 (But if you really do think this is insurmountable, `removeAll(of: 3)` 
 *is* impossible to misinterpret and fits in better than 
 `removeAll(equalTo:)`.)
 
 (P.S. The existing oddness of `removeFirst(_:)` compared to 
 `removeFirst()` and `removeAll()` is why I proposed last year that it be 
 renamed to `removePrefix(_:)`, which matches the count-taking `prefix(_:)` 
 method.)
 
 -- 
 Brent Royal-Gordon
 Architechies
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> On Apr 8, 2017, at 4:12 PM, Xiaodi Wu  wrote:
> 
> On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any renaming 
> > is off the table, no further changes after Swift 4, and it's either this or 
> > being stuck with 'fileprivate' until the end of time, then +1 from me. It 
> > will increase the convenience of access control for people like me who see 
> > types and their extensions as parts of the same entity, just spread 
> > visually across neighboring blocks. In almost any other language these two 
> > would indeed be one entity, since most languages don't have any way of 
> > dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
> > 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
> > back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
> > suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics;
> 
> If I recall correctly, Chris in post-review discussions communicated that a 
> new keyword to replace `fileprivate` would be considered if `fileprivate` 
> turned out to be commonly used enough to be aesthetically problematic?

Yes.  We would consider it.  Chris probably believes that we're more likely to 
accept that change than I do; that's why I was careful to say that I was just 
speaking for myself.  (Chris didn't need to say that explicitly in his message 
because he wasn't explicitly speaking for the Core Team in other parts.)

> I bring this up because, in replying to BJ Homer, it occurs to me that there 
> is an interesting solution. If--as I understand--successive access modifiers 
> being supersets of preceding ones is a non-negotiable part of the design, 
> then type-based access modifiers cannot be accommodated in Swift because of 
> the existence of extensions. Ergo, the word "protected" cannot ever be used 
> to mean what it does in C++, etc. It is a perfectly nice word that by its 
> dictionary meaning is plausibly intermediate between "private" and 
> "internal," which we can repurpose to mean protected by the end of file! By 
> co-opting this word, it has the key virtue of definitively demonstrating that 
> Swift cannot and will not support access modifiers that are tied to types.

I wouldn't say that successive access modifiers being supersets of existing 
ones is a part of the design.  We've been reluctant to change *existing* 
modifiers in ways that aren't just weakening them, but that's different.

That said, "protected" is a pretty valuable keyword, and there have been 
several other interesting proposals for it, especially for things that lie on 
the other side of "internal".  I wouldn't want to burn "protected" until we've 
gotten a complete enough picture of what access problems library developers are 
having that we're sure it's not more useful there.

John.


> 
> it would have to be because 'fileprivate' seemed inappropriate for some new 
> generalization, e.g. if we added sub-file submodules and wanted 'fileprivate' 
> to allow access only within the submodule.  That is assuming a lot about how 
> a future submodule feature would work, and we aren't going to design that 
> feature specifically with a goal of replacing this keyword, and frankly we 
> don't know when we're going to take that on at all.  I would caution people 
> against assuming that 'fileprivate' will be renamed.
> 
> > 3) Postpone this until we add submodules, but with the assumption that it 
> > will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature —

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

[David Hart via swift-evolution]

> On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution 
>  wrote:
> 
> How about this:
> 
> array.removeEvery(3)
> array.removeEvery{ $0 > 3 }
> 
> I think it preserves the meaning while it reads nicely. However "every" has 
> no precedent in other functions, as far as I know.

Every has a very ambiguous meaning in English. It could be understood as "every 
3 values" as in 0, 3, 6, 9, etc...

>> Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution 
>> :
>> 
>> 
 On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon  
 wrote:
 
 On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 +1. Perfect. Let's not bikeshed this and get it done!
>>> 
>>> 
>>> Sorry, I'm going to have to insist on bikeshedding.
>>> 
>>> `equalTo:` is kind of ugly and has no precedent in the standard library. 
>>> Similar APIs seem to either leave the parameter unlabeled or use `of:` (as 
>>> in `index(of:)`). I think unlabeled is probably the right answer here.
>>> 
>> 
>> I think removeAll(of:) works well for the equatable value version.
>> 
>> FWIW of all the ideas from the all thread, containsOnly(_:) for the 
>> equatable value version works for me. It has a nice symmetry: contains(3) vs 
>> containsOnly(3).
>> 
>>> The main shortcoming I can see is that if you see:
>>> 
>>> array.removeAll(3)
>>> 
>> 
>> Personally don’t feel good about an unlabelled version. It doesn’t read 
>> right. Remove all three what?
>> 
>>> You might think `3` is either an index or a count. But neither of those 
>>> actually make sense:
>>> 
>>> * It can't be an index because then `All` would have no meaning. There's 
>>> only ever one thing at a given index. Besides, indices are almost always 
>>> marked with `at:` or another parameter label.
>>> * It can't be a count because `All` is already a count. What could "remove 
>>> all 3" possibly mean if the array doesn't happen to have three elements?
>>> 
>>> And this is only a problem if the value happens to be an integer. If it's 
>>> anything else, the type makes clear that this can't possibly be an index or 
>>> count; it must be an element.
>>> 
>>> (But if you really do think this is insurmountable, `removeAll(of: 3)` *is* 
>>> impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)
>>> 
>>> (P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` 
>>> and `removeAll()` is why I proposed last year that it be renamed to 
>>> `removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 1:04 PM, Daniel Duan  wrote:
> 
>> 
>> On Apr 10, 2017, at 10:52 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
>>> 
>>> No offense taken. 
>>> 
>>> There's no inherent problem with designing language with available tools in 
>>> mind. After all, what we put in the language is a strict subset of what's 
>>> viable in a compiler. 
>>> 
>>> IMHO Swift should care more about separation of language and tools due to 
>>> its long-term ambition: is it a good language out side of the most typical 
>>> experience? If I edit the source with my favorite editor, on Linux, and/or 
>>> compile with an alternative compiler, can I get a similar experience ?
>>> 
>>> A language that conquers the world shouldn't depend on tools to be awesome.
>> 
>> I agree with this.  I just don’t think inference depends on tools.  It only 
>> depends on reasonable judgement by authors.  The same can be said for many 
>> features that we don’t want to do without.  Inference just happens to be an 
>> area where tools can help out when 1) a beginner or someone new to Swift is 
>> reading the code or 2) the author left off an annotation where maybe they 
>> should have included one.
> I’d argue that a fix-it suggestion should do. Tools can go above and beyond 
> what the the language defines of course. 

How would the fix-it stay out of the way when the annotation really isn’t 
intended?  

>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
 
 
> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are 
> using tools with certain capability is kind of a bad thing.
 
 I see this sentiment on this list a lot. Where does it come from? Is there 
 any supporting research? What drives it?
 
 (I don’t mean to pick on Daniel - I’m curious about this overall from 
 anyone that has sources. It has become such a prevailing refrain at times 
 that I think it’d be best for everyone if we knew if it was even true!)
 
 l8r
 Sean

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

> On Apr 10, 2017, at 10:52 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
>> 
>> No offense taken. 
>> 
>> There's no inherent problem with designing language with available tools in 
>> mind. After all, what we put in the language is a strict subset of what's 
>> viable in a compiler. 
>> 
>> IMHO Swift should care more about separation of language and tools due to 
>> its long-term ambition: is it a good language out side of the most typical 
>> experience? If I edit the source with my favorite editor, on Linux, and/or 
>> compile with an alternative compiler, can I get a similar experience ?
>> 
>> A language that conquers the world shouldn't depend on tools to be awesome.
> 
> I agree with this.  I just don’t think inference depends on tools.  It only 
> depends on reasonable judgement by authors.  The same can be said for many 
> features that we don’t want to do without.  Inference just happens to be an 
> area where tools can help out when 1) a beginner or someone new to Swift is 
> reading the code or 2) the author left off an annotation where maybe they 
> should have included one.
I’d argue that a fix-it suggestion should do. Tools can go above and beyond 
what the the language defines of course. 
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
>>> 
>>> 
 On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
 
 Using tools isn't a bad thing. Designing language assuming users are using 
 tools with certain capability is kind of a bad thing.
>>> 
>>> I see this sentiment on this list a lot. Where does it come from? Is there 
>>> any supporting research? What drives it?
>>> 
>>> (I don’t mean to pick on Daniel - I’m curious about this overall from 
>>> anyone that has sources. It has become such a prevailing refrain at times 
>>> that I think it’d be best for everyone if we knew if it was even true!)
>>> 
>>> l8r
>>> Sean
>>> 
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
> 
> No offense taken. 
> 
> There's no inherent problem with designing language with available tools in 
> mind. After all, what we put in the language is a strict subset of what's 
> viable in a compiler. 
> 
> IMHO Swift should care more about separation of language and tools due to its 
> long-term ambition: is it a good language out side of the most typical 
> experience? If I edit the source with my favorite editor, on Linux, and/or 
> compile with an alternative compiler, can I get a similar experience ?
> 
> A language that conquers the world shouldn't depend on tools to be awesome.

I agree with this.  I just don’t think inference depends on tools.  It only 
depends on reasonable judgement by authors.  The same can be said for many 
features that we don’t want to do without.  Inference just happens to be an 
area where tools can help out when 1) a beginner or someone new to Swift is 
reading the code or 2) the author left off an annotation where maybe they 
should have included one.

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>>> 
>>> Using tools isn't a bad thing. Designing language assuming users are using 
>>> tools with certain capability is kind of a bad thing.
>> 
>> I see this sentiment on this list a lot. Where does it come from? Is there 
>> any supporting research? What drives it?
>> 
>> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
>> that has sources. It has become such a prevailing refrain at times that I 
>> think it’d be best for everyone if we knew if it was even true!)
>> 
>> l8r
>> Sean
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

No offense taken. 

There's no inherent problem with designing language with available tools in 
mind. After all, what we put in the language is a strict subset of what's 
viable in a compiler. 

IMHO Swift should care more about separation of language and tools due to its 
long-term ambition: is it a good language out side of the most typical 
experience? If I edit the source with my favorite editor, on Linux, and/or 
compile with an alternative compiler, can I get a similar experience ?

A language that conquers the world shouldn't depend on tools to be awesome.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
> 
> I see this sentiment on this list a lot. Where does it come from? Is there 
> any supporting research? What drives it?
> 
> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
> that has sources. It has become such a prevailing refrain at times that I 
> think it’d be best for everyone if we knew if it was even true!)
> 
> l8r
> Sean
> 

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato via swift-evolution]

On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:

> But even outside the generated code use cases, it's nice to just be able
> to implement helpers or additional "convenience" conformances in separate
> files named appropriately (like "Type+Protocol.swift" or
> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>
> No doubt about the usefulness of having separate files with extensions here
>
> If nothing else, nested extensions could save those who actually don't
> care much about such issues from another breaking change in Swift — and
> imho it adds consistency:
> We can nest types, so why can't we nest extensions?
>
>
> Because types and extensions are quite different beasts, so something that
> applies to one doesn't necessarily apply to the other.
>
> I don't buy this argument at all without an objective explanation why the
> curly braces of extensions should be treated different than the curly
> braces of types...
>

They shouldn't be. That's why I don't support SE-0169 either, because it
would allow extensions to extend the *scope* rather than the *type*, but
only within the same file. I think that's fundamentally broken.

But my comment wasn't about curly braces—it was about types vs. extensions.
For example, you can declare local types within a function, but you can't
extend a type within a function (nor do I think it would be a good idea).



>
> I don't think that holds its weight. This feels like another case of
> "let's try to satisfy everyone who's unhappy with some part of Swift
> visibility by changing a completely different feature to make things fall
> into place", which I don't think is a sound motivation or design principle.
> The example you posted in your initial message weaves multiple
> types/nesting levels together in a way that looks *incredibly* difficult to
> follow/parse to even an experienced user of the language.
>
> Did you noticed that I started this example as mockery? In real life, I
> would hopefully never nest more than once… and do you think sprinkling
> parts of class over the project is easier to follow?
>

Depending on the type, yes. I wouldn't sprinkle the *fundamental/core*
parts of a type across the project, but if there's some kind of "aside"
functionality that doesn't depend on private knowledge of the type, then I
find it to be a nice feature to have. It requires me to have reasonable
names to my source files, but that's not a significant burden.



>
> Everyone seems to be striving for a "perfect" level of access control that
> lets individual types/members dictate precisely what other types/members
> can access them. I'm not sure if that perfection is attainable or not, but
> even if it is, I don't think it's something we should strive for. I'd
> rather have a simple visibility model that leaks a little than an air-tight
> model that allows people to write overly complicated code for the sake of
> fine-tuning access.
>
> I had no desire to change the model of Swift 2 — but apparently, others
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple
> model like nesting over a complicated one with less power.
>
> Let's remember that the core team has limited resources to implement the
> things we propose, and if I have to choose between, say, serialization,
> reflection, asynchronous constructs, and rehashing visibility levels yet
> again, it's clear to me which one I would want dropped on the floor. I
> don't want perfect to be the enemy of good.
>
> Well, right now, there are several (at least one ;-) proposals that aim
> for a breaking change of the whole model… nested extensions break nothing,
> so it can be delayed for as long as the core team likes, without causing
> any trouble.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 10:22 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types…
>> Extensions are not Partials. 
>>> do you think sprinkling parts of class over the project is easier to follow?
>> Extensions are not Partials. 
> I can't see how statement and answer(?) are related to the original post… or 
> did I miss that this topic is about partials? :)
I am partial to partials. :)
> 
>>> it can be delayed for as long as the core team likes, without causing any 
>>> trouble.
>> Partials limited to the same scope can do the same
> That is true… so can we agree that nothing should change now, so that 
> something can be added later? ;-)
Same page. 
> 
>> with out having to give extension special nesting powers :)
> I would say there's no doubt that extensions are withhold the common nesting 
> powers of all other, similar constructs in Swift: Classes can be nested, 
> Structs can be nested, Enums can be nested, functions can be nested, 
> protocols… I haven't tried yet, but associated objects are something 
> comparable ;-)

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Charlie Monroe via swift-evolution]

> On Apr 10, 2017, at 7:22 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
> 
> I see this sentiment on this list a lot. Where does it come from? Is there 
> any supporting research? What drives it?

I personally am one of those people advocating not to design it around an IDE 
for these reasons:

- GitHub (or other SCM)
- support for other OSs (as Swift is designed not just for Mac/iOS)
- non-Xcode IDEs. Believe it or not, from time to time I reach for other apps, 
such as CodeRunner.


> 
> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
> that has sources. It has become such a prevailing refrain at times that I 
> think it’d be best for everyone if we knew if it was even true!)
> 
> l8r
> Sean
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are using 
> tools with certain capability is kind of a bad thing.

I see this sentiment on this list a lot. Where does it come from? Is there any 
supporting research? What drives it?

(I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
that has sources. It has become such a prevailing refrain at times that I think 
it’d be best for everyone if we knew if it was even true!)

l8r
Sean

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.

My understanding is that the slowdowns are produced when the inference has to 
take into account generics. If somebody is using lots of generics and 
overloads; I would hope they would know that this can slow down compile times. 
I am not sure how this can be communicated to the user other than showing a 
warning. 


> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> ___
> 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] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

>> I don't buy this argument at all without an objective explanation why the 
>> curly braces of extensions should be treated different than the curly braces 
>> of types…
> Extensions are not Partials. 
>> do you think sprinkling parts of class over the project is easier to follow?
> Extensions are not Partials. 
I can't see how statement and answer(?) are related to the original post… or 
did I miss that this topic is about partials? :)

>> it can be delayed for as long as the core team likes, without causing any 
>> trouble.
> Partials limited to the same scope can do the same
That is true… so can we agree that nothing should change now, so that something 
can be added later? ;-)

> with out having to give extension special nesting powers :)
I would say there's no doubt that extensions are withhold the common nesting 
powers of all other, similar constructs in Swift: Classes can be nested, 
Structs can be nested, Enums can be nested, functions can be nested, protocols… 
I haven't tried yet, but associated objects are something comparable ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

That's kind of my perspective too. Personally I adore this feature. But 
compiling speed is such a severe issue at work that I'm willing to part with 
it. (Not saying other arguments aren't important).

I'm lucky enough to work on a project that is:
1. purely Swift
2. Vigilantly monitored for compilation slow-down from complex expressions
3. Really large (enough that compiling speed is a severe problem).

I think with time more and more ppl will experience the same thing.  

As I noted in the proposal, swiftc has space for speed improvement in this area 
and I believe the implementators will get there. In the mean time inference may 
still pose a theoretic performance upper bound. 

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:51 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
>> 
>> Where tools *can* help is if the tools enhance the language user's 
>> experience, which is why I proposed the inference capabilities be kept for 
>> diagnostics.
>> 
>> I also disagree with the characterization that types in properties is 
>> "clustering up" the code. The value inference provided here is make the 
>> authoring experience better. I can see for obvious default expressions 
>> (string/number literal perhaps) the readability isn't degraded by too much. 
>> But it's not as clear as explicit types for the *reader*.
> 
> I said “cluttering”, not “clustering” (which has a more derogatory 
> implication for many people).  
> 
> In any case, this is an area where there are differing perspectives each with 
> some merit.  I think it’s best to leave it up to each of us what makes the 
> most sense for our code.  IMO, and that of at least some others who have 
> commented, some code is more clear to readers with annotations and some is 
> more clear to readers without annotations.  
> 
> Like I said earlier, I’m willing to keep an open mind on proposals in this 
> area but I don’t support a wholesale ban on inference directly initialized 
> member declarations.  It may not be possible to do something less than a 
> wholesale ban without introducing more confusion than we have today as to 
> when inference is permitted and when it isn’t.  If it isn’t that’s ok with 
> me.  If it is, I’ll consider such a proposal on its merit if one is brought 
> forward.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  wrote:
>>> 
>>> 
 On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
 
 I guess I'm using the word "export" loosely. Often times I find myself 
 reading type signatures in my own codebase either because it's written by 
 someone else on my team or by myself long time ago. I think open-source 
 library users have the same problem. Exposure to a particular local 
 variable is less likely.
>>> 
>>> If you’re reading code in a codebase you work on most of the time you’ll be 
>>> reading it using a tool that can give you the annotation using something 
>>> like opt-click in Xcode.  I don’t think it’s worth cluttering up our code 
>>> with annotations that are readily available to most readers.  Most of the 
>>> time annotations introduce noise that reduces clarity.  I don’t think 
>>> relying on tools in the occasional case where the type isn’t obvious to an 
>>> individual reader is a bad thing.
>>> 
 
 Daniel Duan
 Sent from my iPhone
 
>> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  
>> wrote:
>> 
>> 
>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> I’m not questioning the value of type inference in general. Just that 
>> there are practical implications when we want more of them. There’s a 
>> difference in inferencing type declaration properties and local 
>> variables: the former is more likely to be exported and read by others. 
>> These arguments are all in the draft proposal.
> 
> When a declaration is exported outside a module whoever is reading it 
> isn’t reading the source directly.  They are reading documentation or a 
> generated header of some kind.  The annotation can easily be added by 
> tools that produce these.
> 
>> 
>>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>>> 
>>> Well, I’m not really a beginner, but for me personally, the computer is 
>>> here to help me do my work and to do some of the thinking for me. I 
>>> really hate repeating myself when it comes to types - especially if the 
>>> types get wordy (collections, etc). Swift is pretty good about it - but 
>>> these warts stick out. The idea that we should make it *less* good at 
>>> this really rubs me the wrong way. How many times have you seen lines 
>>> of code like this in C++-ish/C#-ish languages:
>>> 
>>>

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

[piotr gorzelany via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md

This is a really great proposal. As an iOS developer I work with JSON
almost every day since most mobile apps communicate with a backend through
JSON messages. It's good to see that better JSON support is coming to
Foundation so we don't have to rely on third party libraries.

That being said, there is one thing I don't like which is that the JSON
encoding function returns Data and the decoding function takes Data.

It would be really great if the Foundation team could introduce a dedicated
type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for
manipulating JSON
- It makes it explicit what you are dealing with

A good analogy is the URL type. You could represent an URL with a String or
Data type, but by introducing a dedicated type you have the full advantages
mentioned above. Data on the other hand is like a generic container which
you cannot easily extend with URL or JSON specific methods.

Having a dedicated JSON type is also one of the reasons third party
libraries like SwiftyJSON are so popular. It makes it super easy to
manipulate JSON structures. And sometimes developers like would like to
manipulate JSON directly.

If the proposal would pass in the current form, I would still use
SwiftyJSON for manipulating JSON which I would rather avoid and have this
all sorted on the Foundation level.

Just my two cents from the perspective of an iOS developer. JSON handling
is really important to us so I hope you make it great!

>* On Apr 3, 2017, at 1:31 PM, Itai Ferber via swift-evolution at swift.org > wrote:
*>* Hi everyone,
*> >* With feedback from swift-evolution and additional internal
review, we've pushed updates to this proposal, and to the Swift
Archival & Serialization proposal.
*>* Changes to here mostly mirror the ones made to Swift Archival &
Serialization, but you can see a specific diff of what's changed here.
Full content below.
*> >* We'll be looking to start the official review process very soon,
so we're interested in any additional feedback.
*> >* Thanks!
*> >* — Itai*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Johannes Lund via swift-evolution]

Hi!

To begin with, I have three questions:
1. Are these proposals purely meant for archival or do they also aim to be the 
basis of an optimal solution for decoding/unmarshalling JSON from external APIs?
2. How are Optionals of Codable types handled? I see no mentions of this. Do 
they map to missing keys and/or null, or are they not handled automatically at 
all?
3. If you’re writing a lot of custom decoding code, how are you supposed to 
debug errors? Do the error messages contain metadata? (I see no traces of it, 
but could happen behind the scenes) Or should you rely merely on Swift Error 
breakpoints?

/Johannes Lund

> 6 apr. 2017 kl. 20:10 skrev Douglas Gregor :
> 
> Hello Swift community,
> 
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

[Josh Parmenter via swift-evolution]

On Apr 10, 2017, at 9:53 AM, Kevin Nattinger 
mailto:sw...@nattinger.net>> wrote:


On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:

case .none isn’t handled.

It shouldn’t need to be handled in the second switch because it’s impossible. 
Not just developer thinks “impossible” but easily provable by static analysis 
the compiler is doing it anyway—I wouldn’t be surprised if including the case 
resulted in an “unreachable code” warning (in fact, it probably should).

Why? Because of preconditionFailure? That COULD be optimized out as per this 
documentation:

/// * In `-Ounchecked` builds, the optimizer may assume that this function is
///   never called. Failure to satisfy that assumption is a serious
///   programming error.

So I’m not sure if that is the case or not.

This should probably be on the swift-users list though, no?

File a bug, IMO.

Yes - it should probably be looked at by someone who would know if this a bug 
or the expected behavior.

Best,
Josh


Best,
Josh



On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
mailto:swift-evolution@swift.org>>
 wrote:



Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
   switch(operation) {
   case .push: /* snip */ break
   case .pop: /* snip */ break
   default:
   preconditionFailure("This is a silly operation")
   }
   switch(operation) {
   case .push: /* snip */ break
   case .pop: /* snip */ break
//error: Switch must be exhaustive, consider adding a default clause
   }
}

The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

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


Joshua Parmenter | Engineering Lead, Apple Technologies

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

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

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

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> But even outside the generated code use cases, it's nice to just be able to 
>> implement helpers or additional "convenience" conformances in separate files 
>> named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I 
>> find it makes my codebase easier to navigate.
> No doubt about the usefulness of having separate files with extensions here
> 
>> If nothing else, nested extensions could save those who actually don't care 
>> much about such issues from another breaking change in Swift — and imho it 
>> adds consistency:
>> We can nest types, so why can't we nest extensions?
>> 
>> Because types and extensions are quite different beasts, so something that 
>> applies to one doesn't necessarily apply to the other.
> I don't buy this argument at all without an objective explanation why the 
> curly braces of extensions should be treated different than the curly braces 
> of types…
Extensions are not Partials. 
> 
>> I don't think that holds its weight. This feels like another case of "let's 
>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>> changing a completely different feature to make things fall into place", 
>> which I don't think is a sound motivation or design principle. The example 
>> you posted in your initial message weaves multiple types/nesting levels 
>> together in a way that looks *incredibly* difficult to follow/parse to even 
>> an experienced user of the language.
> Did you noticed that I started this example as mockery? In real life, I would 
> hopefully never nest more than once… and do you think sprinkling parts of 
> class over the project is easier to follow?
Extensions are not Partials. 
> 
>> Everyone seems to be striving for a "perfect" level of access control that 
>> lets individual types/members dictate precisely what other types/members can 
>> access them. I'm not sure if that perfection is attainable or not, but even 
>> if it is, I don't think it's something we should strive for. I'd rather have 
>> a simple visibility model that leaks a little than an air-tight model that 
>> allows people to write overly complicated code for the sake of fine-tuning 
>> access.
> I had no desire to change the model of Swift 2 — but apparently, others 
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
> model like nesting over a complicated one with less power.
> 
>> Let's remember that the core team has limited resources to implement the 
>> things we propose, and if I have to choose between, say, serialization, 
>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>> again, it's clear to me which one I would want dropped on the floor. I don't 
>> want perfect to be the enemy of good.
> Well, right now, there are several (at least one ;-) proposals that aim for a 
> breaking change of the whole model… nested extensions break nothing, so it 
> can be delayed for as long as the core team likes, without causing any 
> trouble.
Partials limited to the same scope can do the same with out having to give 
extension special nesting powers :)
> ___
> 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] switch must be exhaustive, consider adding a default clause

[Kevin Nattinger via swift-evolution]

> On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution 
>  wrote:
> 
> case .none isn’t handled.

It shouldn’t need to be handled in the second switch because it’s impossible. 
Not just developer thinks “impossible” but easily provable by static analysis 
the compiler is doing it anyway—I wouldn’t be surprised if including the case 
resulted in an “unreachable code” warning (in fact, it probably should).

> This should probably be on the swift-users list though, no?

File a bug, IMO. 

> Best,
> Josh
> 
> 
> 
> On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
>   >> wrote:
> 
> 
> 
> Is there a good reason we do not compile this:
> 
> import UIKit
> 
> func foo(operation: UINavigationControllerOperation) {
>switch(operation) {
>case .push: /* snip */ break
>case .pop: /* snip */ break
>default:
>preconditionFailure("This is a silly operation")
>}
>switch(operation) {
>case .push: /* snip */ break
>case .pop: /* snip */ break
> //error: Switch must be exhaustive, consider adding a default clause
>}
> }
> 
> The switch *is* exhaustive, because the default case is unreachable.  The 
> compiler could infer as much from branch analysis.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
>  >
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> Joshua Parmenter | Engineering Lead, Apple Technologies
> 
> T 248 777 
> C 206 437 1551
> F 248 616 1980
> www.vectorform.com  >
> 
> Vectorform
> 2107 Elliott Ave Suite 303
> Seattle, WA  98121 USA
> 
> Think Tank. Lab. Studio.
> We invent digital products and experiences.
> 
> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are using 
> tools with certain capability is kind of a bad thing.
> 
> Where tools *can* help is if the tools enhance the language user's 
> experience, which is why I proposed the inference capabilities be kept for 
> diagnostics.
> 
> I also disagree with the characterization that types in properties is 
> "clustering up" the code. The value inference provided here is make the 
> authoring experience better. I can see for obvious default expressions 
> (string/number literal perhaps) the readability isn't degraded by too much. 
> But it's not as clear as explicit types for the *reader*.

I said “cluttering”, not “clustering” (which has a more derogatory implication 
for many people).  

In any case, this is an area where there are differing perspectives each with 
some merit.  I think it’s best to leave it up to each of us what makes the most 
sense for our code.  IMO, and that of at least some others who have commented, 
some code is more clear to readers with annotations and some is more clear to 
readers without annotations.  

Like I said earlier, I’m willing to keep an open mind on proposals in this area 
but I don’t support a wholesale ban on inference directly initialized member 
declarations.  It may not be possible to do something less than a wholesale ban 
without introducing more confusion than we have today as to when inference is 
permitted and when it isn’t.  If it isn’t that’s ok with me.  If it is, I’ll 
consider such a proposal on its merit if one is brought forward.

> 
> Daniel Duan
> Sent from my iPhone
> 
> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  > wrote:
> 
>> 
>>> On Apr 10, 2017, at 11:22 AM, Daniel Duan >> > wrote:
>>> 
>>> I guess I'm using the word "export" loosely. Often times I find myself 
>>> reading type signatures in my own codebase either because it's written by 
>>> someone else on my team or by myself long time ago. I think open-source 
>>> library users have the same problem. Exposure to a particular local 
>>> variable is less likely.
>> 
>> If you’re reading code in a codebase you work on most of the time you’ll be 
>> reading it using a tool that can give you the annotation using something 
>> like opt-click in Xcode.  I don’t think it’s worth cluttering up our code 
>> with annotations that are readily available to most readers.  Most of the 
>> time annotations introduce noise that reduces clarity.  I don’t think 
>> relying on tools in the occasional case where the type isn’t obvious to an 
>> individual reader is a bad thing.
>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Apr 10, 2017, at 9:16 AM, Matthew Johnson >>> > wrote:
 
 
> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> I’m not questioning the value of type inference in general. Just that 
> there are practical implications when we want more of them. There’s a 
> difference in inferencing type declaration properties and local 
> variables: the former is more likely to be exported and read by others. 
> These arguments are all in the draft proposal.
 
 When a declaration is exported outside a module whoever is reading it 
 isn’t reading the source directly.  They are reading documentation or a 
 generated header of some kind.  The annotation can easily be added by 
 tools that produce these.
 
> 
>> On Apr 10, 2017, at 9:07 AM, Sean Heber > > wrote:
>> 
>> Well, I’m not really a beginner, but for me personally, the computer is 
>> here to help me do my work and to do some of the thinking for me. I 
>> really hate repeating myself when it comes to types - especially if the 
>> types get wordy (collections, etc). Swift is pretty good about it - but 
>> these warts stick out. The idea that we should make it *less* good at 
>> this really rubs me the wrong way. How many times have you seen lines of 
>> code like this in C++-ish/C#-ish languages:
>> 
>> Foo foo = new Foo();
>> 
>> Every time I see that sort of thing, I cringe a little.
>> 
>> IMO if you wanted to be super opinionated, the language would actually 
>> warn if you did this:
>> 
>> let foo: Foo = Foo()
>> 
>> And offer a fixit to:
>> 
>> let foo = Foo()
>> 
>> With no warning for things like this because you’re obviously doing 
>> something intentional:
>> 
>> let foo: FooSuperclass = Foo()
>> 
>> But I’d settle for no warnings and getting the inference to work in all 
>> contexts. :)
>> 
>> l8r
>> Sean
>> 
>> 
>>> On Apr 10, 2017, at 10:58 AM, Daniel Duan >> > wrote:
>>> 
>>> It is 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> But even outside the generated code use cases, it's nice to just be able to 
> implement helpers or additional "convenience" conformances in separate files 
> named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I 
> find it makes my codebase easier to navigate.
No doubt about the usefulness of having separate files with extensions here

> If nothing else, nested extensions could save those who actually don't care 
> much about such issues from another breaking change in Swift — and imho it 
> adds consistency:
> We can nest types, so why can't we nest extensions?
> 
> Because types and extensions are quite different beasts, so something that 
> applies to one doesn't necessarily apply to the other.
I don't buy this argument at all without an objective explanation why the curly 
braces of extensions should be treated different than the curly braces of 
types...

> I don't think that holds its weight. This feels like another case of "let's 
> try to satisfy everyone who's unhappy with some part of Swift visibility by 
> changing a completely different feature to make things fall into place", 
> which I don't think is a sound motivation or design principle. The example 
> you posted in your initial message weaves multiple types/nesting levels 
> together in a way that looks *incredibly* difficult to follow/parse to even 
> an experienced user of the language.
Did you noticed that I started this example as mockery? In real life, I would 
hopefully never nest more than once… and do you think sprinkling parts of class 
over the project is easier to follow?

> Everyone seems to be striving for a "perfect" level of access control that 
> lets individual types/members dictate precisely what other types/members can 
> access them. I'm not sure if that perfection is attainable or not, but even 
> if it is, I don't think it's something we should strive for. I'd rather have 
> a simple visibility model that leaks a little than an air-tight model that 
> allows people to write overly complicated code for the sake of fine-tuning 
> access.
I had no desire to change the model of Swift 2 — but apparently, others thought 
it wasn't sufficient, and I'd rather prefer a conceptually simple model like 
nesting over a complicated one with less power.

> Let's remember that the core team has limited resources to implement the 
> things we propose, and if I have to choose between, say, serialization, 
> reflection, asynchronous constructs, and rehashing visibility levels yet 
> again, it's clear to me which one I would want dropped on the floor. I don't 
> want perfect to be the enemy of good.
Well, right now, there are several (at least one ;-) proposals that aim for a 
breaking change of the whole model… nested extensions break nothing, so it can 
be delayed for as long as the core team likes, without causing any trouble.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

Using tools isn't a bad thing. Designing language assuming users are using 
tools with certain capability is kind of a bad thing.

Where tools *can* help is if the tools enhance the language user's experience, 
which is why I proposed the inference capabilities be kept for diagnostics.

I also disagree with the characterization that types in properties is 
"clustering up" the code. The value inference provided here is make the 
authoring experience better. I can see for obvious default expressions 
(string/number literal perhaps) the readability isn't degraded by too much. But 
it's not as clear as explicit types for the *reader*.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
>> 
>> I guess I'm using the word "export" loosely. Often times I find myself 
>> reading type signatures in my own codebase either because it's written by 
>> someone else on my team or by myself long time ago. I think open-source 
>> library users have the same problem. Exposure to a particular local variable 
>> is less likely.
> 
> If you’re reading code in a codebase you work on most of the time you’ll be 
> reading it using a tool that can give you the annotation using something like 
> opt-click in Xcode.  I don’t think it’s worth cluttering up our code with 
> annotations that are readily available to most readers.  Most of the time 
> annotations introduce noise that reduces clarity.  I don’t think relying on 
> tools in the occasional case where the type isn’t obvious to an individual 
> reader is a bad thing.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
 On Apr 10, 2017, at 9:16 AM, Matthew Johnson  
 wrote:
 
 
 On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
  wrote:
 
 I’m not questioning the value of type inference in general. Just that 
 there are practical implications when we want more of them. There’s a 
 difference in inferencing type declaration properties and local variables: 
 the former is more likely to be exported and read by others. These 
 arguments are all in the draft proposal.
>>> 
>>> When a declaration is exported outside a module whoever is reading it isn’t 
>>> reading the source directly.  They are reading documentation or a generated 
>>> header of some kind.  The annotation can easily be added by tools that 
>>> produce these.
>>> 
 
> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
> 
> Well, I’m not really a beginner, but for me personally, the computer is 
> here to help me do my work and to do some of the thinking for me. I 
> really hate repeating myself when it comes to types - especially if the 
> types get wordy (collections, etc). Swift is pretty good about it - but 
> these warts stick out. The idea that we should make it *less* good at 
> this really rubs me the wrong way. How many times have you seen lines of 
> code like this in C++-ish/C#-ish languages:
> 
> Foo foo = new Foo();
> 
> Every time I see that sort of thing, I cringe a little.
> 
> IMO if you wanted to be super opinionated, the language would actually 
> warn if you did this:
> 
> let foo: Foo = Foo()
> 
> And offer a fixit to:
> 
> let foo = Foo()
> 
> With no warning for things like this because you’re obviously doing 
> something intentional:
> 
> let foo: FooSuperclass = Foo()
> 
> But I’d settle for no warnings and getting the inference to work in all 
> contexts. :)
> 
> l8r
> Sean
> 
> 
>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>> 
>> It is helpful in the sense that it tells us what’s really inconsistent: 
>> beginner’s have to learn when inference is available when declaring 
>> their types. That’s story is sketchy.
>>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>>> 
>>> This is not really a helpful comment, but: I kinda wish they did.
>>> 
>>> l8r
>>> Sean
>>> 
 On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Neither of these works btw.
 
 func bar(myString = “hello”)
 class Baz {
 let myString = { return “hello” }()
 }
 
> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How 
> do you explain a new comer that type inference work in some case, but 
> not in other cases, while in both the compiler is completely capable 
> to define the type.
> 
> Why 
> 
> let myString = "hello" 
> 
> would be accepted but not 
> 
> class Foo {
>   let myString = "hello" 
> }
> 
> 
> 
>> Le 10 avr. 2017 à 04:05, Daniel Duan via sw

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
> 
> I guess I'm using the word "export" loosely. Often times I find myself 
> reading type signatures in my own codebase either because it's written by 
> someone else on my team or by myself long time ago. I think open-source 
> library users have the same problem. Exposure to a particular local variable 
> is less likely.

If you’re reading code in a codebase you work on most of the time you’ll be 
reading it using a tool that can give you the annotation using something like 
opt-click in Xcode.  I don’t think it’s worth cluttering up our code with 
annotations that are readily available to most readers.  Most of the time 
annotations introduce noise that reduces clarity.  I don’t think relying on 
tools in the occasional case where the type isn’t obvious to an individual 
reader is a bad thing.

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> I’m not questioning the value of type inference in general. Just that there 
>>> are practical implications when we want more of them. There’s a difference 
>>> in inferencing type declaration properties and local variables: the former 
>>> is more likely to be exported and read by others. These arguments are all 
>>> in the draft proposal.
>> 
>> When a declaration is exported outside a module whoever is reading it isn’t 
>> reading the source directly.  They are reading documentation or a generated 
>> header of some kind.  The annotation can easily be added by tools that 
>> produce these.
>> 
>>> 
 On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
 
 Well, I’m not really a beginner, but for me personally, the computer is 
 here to help me do my work and to do some of the thinking for me. I really 
 hate repeating myself when it comes to types - especially if the types get 
 wordy (collections, etc). Swift is pretty good about it - but these warts 
 stick out. The idea that we should make it *less* good at this really rubs 
 me the wrong way. How many times have you seen lines of code like this in 
 C++-ish/C#-ish languages:
 
 Foo foo = new Foo();
 
 Every time I see that sort of thing, I cringe a little.
 
 IMO if you wanted to be super opinionated, the language would actually 
 warn if you did this:
 
 let foo: Foo = Foo()
 
 And offer a fixit to:
 
 let foo = Foo()
 
 With no warning for things like this because you’re obviously doing 
 something intentional:
 
 let foo: FooSuperclass = Foo()
 
 But I’d settle for no warnings and getting the inference to work in all 
 contexts. :)
 
 l8r
 Sean
 
 
> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
> 
> It is helpful in the sense that it tells us what’s really inconsistent: 
> beginner’s have to learn when inference is available when declaring their 
> types. That’s story is sketchy.
>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>> 
>> This is not really a helpful comment, but: I kinda wish they did.
>> 
>> l8r
>> Sean
>> 
>>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Neither of these works btw.
>>> 
>>> func bar(myString = “hello”)
>>> class Baz {
>>> let myString = { return “hello” }()
>>> }
>>> 
 On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
 
 I’m full -1 on this one. It will make the language inconsistent. How 
 do you explain a new comer that type inference work in some case, but 
 not in other cases, while in both the compiler is completely capable 
 to define the type.
 
 Why 
 
 let myString = "hello" 
 
 would be accepted but not 
 
 class Foo {
   let myString = "hello" 
 }
 
 
 
> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>  a écrit :
> 
> I’m still not sure whether *I* want this. But here’s a proposal 
> anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, 
>> Slava brought up some performance problems caused by type inference 
>> for stored properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type 
>> declarations. I thin

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

I guess I'm using the word "export" loosely. Often times I find myself reading 
type signatures in my own codebase either because it's written by someone else 
on my team or by myself long time ago. I think open-source library users have 
the same problem. Exposure to a particular local variable is less likely.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> I’m not questioning the value of type inference in general. Just that there 
>> are practical implications when we want more of them. There’s a difference 
>> in inferencing type declaration properties and local variables: the former 
>> is more likely to be exported and read by others. These arguments are all in 
>> the draft proposal.
> 
> When a declaration is exported outside a module whoever is reading it isn’t 
> reading the source directly.  They are reading documentation or a generated 
> header of some kind.  The annotation can easily be added by tools that 
> produce these.
> 
>> 
>>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>>> 
>>> Well, I’m not really a beginner, but for me personally, the computer is 
>>> here to help me do my work and to do some of the thinking for me. I really 
>>> hate repeating myself when it comes to types - especially if the types get 
>>> wordy (collections, etc). Swift is pretty good about it - but these warts 
>>> stick out. The idea that we should make it *less* good at this really rubs 
>>> me the wrong way. How many times have you seen lines of code like this in 
>>> C++-ish/C#-ish languages:
>>> 
>>> Foo foo = new Foo();
>>> 
>>> Every time I see that sort of thing, I cringe a little.
>>> 
>>> IMO if you wanted to be super opinionated, the language would actually warn 
>>> if you did this:
>>> 
>>> let foo: Foo = Foo()
>>> 
>>> And offer a fixit to:
>>> 
>>> let foo = Foo()
>>> 
>>> With no warning for things like this because you’re obviously doing 
>>> something intentional:
>>> 
>>> let foo: FooSuperclass = Foo()
>>> 
>>> But I’d settle for no warnings and getting the inference to work in all 
>>> contexts. :)
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
 
 It is helpful in the sense that it tells us what’s really inconsistent: 
 beginner’s have to learn when inference is available when declaring their 
 types. That’s story is sketchy.
> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
> 
> This is not really a helpful comment, but: I kinda wish they did.
> 
> l8r
> Sean
> 
>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Neither of these works btw.
>> 
>> func bar(myString = “hello”)
>> class Baz {
>> let myString = { return “hello” }()
>> }
>> 
>>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>>> 
>>> I’m full -1 on this one. It will make the language inconsistent. How do 
>>> you explain a new comer that type inference work in some case, but not 
>>> in other cases, while in both the compiler is completely capable to 
>>> define the type.
>>> 
>>> Why 
>>> 
>>> let myString = "hello" 
>>> 
>>> would be accepted but not 
>>> 
>>> class Foo {
>>>let myString = "hello" 
>>> }
>>> 
>>> 
>>> 
 Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
  a écrit :
 
 I’m still not sure whether *I* want this. But here’s a proposal 
 anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
 
> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, 
> Slava brought up some performance problems caused by type inference 
> for stored properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members 
> contemplated requiring types for stored properties in type 
> declarations. I think this idea deserves some more attention. Hence 
> this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, 
> there're always the general benefit of making type declartion more 
> explicit and readable (clarity for reader should out-weigh pleasure 
> of the author). Making the
> language slightly more consistent (we are not inferring types for 
> default parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the 
> language feels more friendly and is, undoubtedly, a beloved feature 
> f

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato via swift-evolution]

On Mon, Apr 10, 2017 at 8:26 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m not sure that this solves anything meaningful (whether in relation to
> SE-0169 or more generally), does it? What advantage does this provide over
> just declaring the protocol conformance and those methods as a direct part
> of the parent type? This seems like it would just introduce more
> indentation, and more lines of code, for zero benefit.
>
> Well, I'm not overwhelmingly convinced of this whole "we put same-module
> stuff into extensions" anyways, so it's debatable wether proposals like
> SE-0169 have any meaningful effects at all… do you think that conformances
> in same-file extensions have a real benefit?
>

Yes—as Matthew already stated, it's mostly organizational, but the
flexibility is nice to have. I like being able to group functionality of a
type not solely within a single set of curly braces or a single file, but
sometimes also into separate files if the situation calls for it.

For example, in Swift protocol buffers we have a handful of types that are
called "well-known types" that are generated from their .proto file, but to
which we also add a number of convenience initializers/methods. Since the
type itself is generated, extensions in separate files let us do this
without having to hack the generator with special cases to inline the code
into the same file.

But even outside the generated code use cases, it's nice to just be able to
implement helpers or additional "convenience" conformances in separate
files named appropriately (like "Type+Protocol.swift" or
"Type+Helpers.swift"). I find it makes my codebase easier to navigate.



> If nothing else, nested extensions could save those who actually don't
> care much about such issues from another breaking change in Swift — and
> imho it adds consistency:
> We can nest types, so why can't we nest extensions?
>

Because types and extensions are quite different beasts, so something that
applies to one doesn't necessarily apply to the other. Nesting extensions
as you described would seem to be not much different than just flattening
the extension's contents into the type directly or moving them out to
file-level, with the only difference being that it adds a new scope for the
purposes of visibility or getting something like "friend" in C++ (but your
example is even more fine-grained than that).

I don't think that holds its weight. This feels like another case of "let's
try to satisfy everyone who's unhappy with some part of Swift visibility by
changing a completely different feature to make things fall into place",
which I don't think is a sound motivation or design principle. The example
you posted in your initial message weaves multiple types/nesting levels
together in a way that looks *incredibly* difficult to follow/parse to even
an experienced user of the language.

Everyone seems to be striving for a "perfect" level of access control that
lets individual types/members dictate precisely what other types/members
can access them. I'm not sure if that perfection is attainable or not, but
even if it is, I don't think it's something we should strive for. I'd
rather have a simple visibility model that leaks a little than an air-tight
model that allows people to write overly complicated code for the sake of
fine-tuning access.

Let's remember that the core team has limited resources to implement the
things we propose, and if I have to choose between, say, serialization,
reflection, asynchronous constructs, and rehashing visibility levels yet
again, it's clear to me which one I would want dropped on the floor. I
don't want perfect to be the enemy of good.



> ___
> 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] switch must be exhaustive, consider adding a default clause

[Josh Parmenter via swift-evolution]

case .none isn’t handled.
This should probably be on the swift-users list though, no?
Best,
Josh



On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:



Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
switch(operation) {
case .push: /* snip */ break
case .pop: /* snip */ break
default:
preconditionFailure("This is a silly operation")
}
switch(operation) {
case .push: /* snip */ break
case .pop: /* snip */ break
 //error: Switch must be exhaustive, consider adding a default clause
}
}

The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

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


Joshua Parmenter | Engineering Lead, Apple Technologies

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

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA  98121 USA

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

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> I’m not questioning the value of type inference in general. Just that there 
> are practical implications when we want more of them. There’s a difference in 
> inferencing type declaration properties and local variables: the former is 
> more likely to be exported and read by others. These arguments are all in the 
> draft proposal.

When a declaration is exported outside a module whoever is reading it isn’t 
reading the source directly.  They are reading documentation or a generated 
header of some kind.  The annotation can easily be added by tools that produce 
these.

> 
>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>> 
>> Well, I’m not really a beginner, but for me personally, the computer is here 
>> to help me do my work and to do some of the thinking for me. I really hate 
>> repeating myself when it comes to types - especially if the types get wordy 
>> (collections, etc). Swift is pretty good about it - but these warts stick 
>> out. The idea that we should make it *less* good at this really rubs me the 
>> wrong way. How many times have you seen lines of code like this in 
>> C++-ish/C#-ish languages:
>> 
>> Foo foo = new Foo();
>> 
>> Every time I see that sort of thing, I cringe a little.
>> 
>> IMO if you wanted to be super opinionated, the language would actually warn 
>> if you did this:
>> 
>> let foo: Foo = Foo()
>> 
>> And offer a fixit to:
>> 
>> let foo = Foo()
>> 
>> With no warning for things like this because you’re obviously doing 
>> something intentional:
>> 
>> let foo: FooSuperclass = Foo()
>> 
>> But I’d settle for no warnings and getting the inference to work in all 
>> contexts. :)
>> 
>> l8r
>> Sean
>> 
>> 
>>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>>> 
>>> It is helpful in the sense that it tells us what’s really inconsistent: 
>>> beginner’s have to learn when inference is available when declaring their 
>>> types. That’s story is sketchy.
 On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
 
 This is not really a helpful comment, but: I kinda wish they did.
 
 l8r
 Sean
 
> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Neither of these works btw.
> 
> func bar(myString = “hello”)
> class Baz {
> let myString = { return “hello” }()
> }
> 
>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>> 
>> I’m full -1 on this one. It will make the language inconsistent. How do 
>> you explain a new comer that type inference work in some case, but not 
>> in other cases, while in both the compiler is completely capable to 
>> define the type.
>> 
>> Why 
>> 
>> let myString = "hello" 
>> 
>> would be accepted but not 
>> 
>> class Foo {
>>  let myString = "hello" 
>> }
>> 
>> 
>> 
>>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>>  a écrit :
>>> 
>>> I’m still not sure whether *I* want this. But here’s a proposal 
>>> anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Hi all,
 
 In a discussion about inferring parameter types from default value, 
 Slava brought up some performance problems caused by type inference 
 for stored properties in side types:
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 
 Towards the end, the post mentioned that some Swift team members 
 contemplated requiring types for stored properties in type 
 declarations. I think this idea deserves some more attention. Hence 
 this last minute idea-floating.
 
 In addition to solving a performance headache in implementation, 
 there're always the general benefit of making type declartion more 
 explicit and readable (clarity for reader should out-weigh pleasure of 
 the author). Making the
 language slightly more consistent (we are not inferring types for 
 default parameter values in function anyways).
 
 The cons for doing this are obvious too: the inference makes the 
 language feels more friendly and is, undoubtedly, a beloved feature 
 for many. This would be a source breaking change.
 
 Just thought I'd float the idea to gather some quick reaction. What do 
 y'all think?
 
 Daniel Duan
 ___
 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

[swift-evolution] switch must be exhaustive, consider adding a default clause

[Drew Crawford via swift-evolution]

Is there a good reason we do not compile this:

import UIKit

func foo(operation: UINavigationControllerOperation) {
    switch(operation) {
    case .push: /* snip */ break
    case .pop: /* snip */ break
    default:
        preconditionFailure("This is a silly operation")
    }
    switch(operation) {
        case .push: /* snip */ break
        case .pop: /* snip */ break
         //error: Switch must be exhaustive, consider adding a default clause
    }
}
The switch *is* exhaustive, because the default case is unreachable.  The 
compiler could infer as much from branch analysis.

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

[swift-evolution] [Pitch] Remove type-inference for stored property

[Seán Labastille via swift-evolution]

Off the top of my head I’m not sure if there is a precedent for such a drastic 
change in behaviour between playgrounds and non-playground compilation.
However, allowing type inference in playgrounds while disallowing this 
otherwise could maintain the benefits for educational and experimental 
scenarios while still eliminating the performance and clarity penalties in 
production (compiled) source files.

> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

I’m not questioning the value of type inference in general. Just that there are 
practical implications when we want more of them. There’s a difference in 
inferencing type declaration properties and local variables: the former is more 
likely to be exported and read by others. These arguments are all in the draft 
proposal.

> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
> 
> Well, I’m not really a beginner, but for me personally, the computer is here 
> to help me do my work and to do some of the thinking for me. I really hate 
> repeating myself when it comes to types - especially if the types get wordy 
> (collections, etc). Swift is pretty good about it - but these warts stick 
> out. The idea that we should make it *less* good at this really rubs me the 
> wrong way. How many times have you seen lines of code like this in 
> C++-ish/C#-ish languages:
> 
> Foo foo = new Foo();
> 
> Every time I see that sort of thing, I cringe a little.
> 
> IMO if you wanted to be super opinionated, the language would actually warn 
> if you did this:
> 
> let foo: Foo = Foo()
> 
> And offer a fixit to:
> 
> let foo = Foo()
> 
> With no warning for things like this because you’re obviously doing something 
> intentional:
> 
> let foo: FooSuperclass = Foo()
> 
> But I’d settle for no warnings and getting the inference to work in all 
> contexts. :)
> 
> l8r
> Sean
> 
> 
>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>> 
>> It is helpful in the sense that it tells us what’s really inconsistent: 
>> beginner’s have to learn when inference is available when declaring their 
>> types. That’s story is sketchy.
>>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>>> 
>>> This is not really a helpful comment, but: I kinda wish they did.
>>> 
>>> l8r
>>> Sean
>>> 
 On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Neither of these works btw.
 
 func bar(myString = “hello”)
 class Baz {
 let myString = { return “hello” }()
 }
 
> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How do 
> you explain a new comer that type inference work in some case, but not in 
> other cases, while in both the compiler is completely capable to define 
> the type.
> 
> Why 
> 
> let myString = "hello" 
> 
> would be accepted but not 
> 
> class Foo {
>   let myString = "hello" 
> }
> 
> 
> 
>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>  a écrit :
>> 
>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>> 
>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> In a discussion about inferring parameter types from default value, 
>>> Slava brought up some performance problems caused by type inference for 
>>> stored properties in side types:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> 
>>> Towards the end, the post mentioned that some Swift team members 
>>> contemplated requiring types for stored properties in type 
>>> declarations. I think this idea deserves some more attention. Hence 
>>> this last minute idea-floating.
>>> 
>>> In addition to solving a performance headache in implementation, 
>>> there're always the general benefit of making type declartion more 
>>> explicit and readable (clarity for reader should out-weigh pleasure of 
>>> the author). Making the
>>> language slightly more consistent (we are not inferring types for 
>>> default parameter values in function anyways).
>>> 
>>> The cons for doing this are obvious too: the inference makes the 
>>> language feels more friendly and is, undoubtedly, a beloved feature for 
>>> many. This would be a source breaking change.
>>> 
>>> Just thought I'd float the idea to gather some quick reaction. What do 
>>> y'all think?
>>> 
>>> Daniel Duan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

Well, I’m not really a beginner, but for me personally, the computer is here to 
help me do my work and to do some of the thinking for me. I really hate 
repeating myself when it comes to types - especially if the types get wordy 
(collections, etc). Swift is pretty good about it - but these warts stick out. 
The idea that we should make it *less* good at this really rubs me the wrong 
way. How many times have you seen lines of code like this in C++-ish/C#-ish 
languages:

Foo foo = new Foo();

Every time I see that sort of thing, I cringe a little.

IMO if you wanted to be super opinionated, the language would actually warn if 
you did this:

let foo: Foo = Foo()

And offer a fixit to:

let foo = Foo()

With no warning for things like this because you’re obviously doing something 
intentional:

let foo: FooSuperclass = Foo()

But I’d settle for no warnings and getting the inference to work in all 
contexts. :)

l8r
Sean


> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
> 
> It is helpful in the sense that it tells us what’s really inconsistent: 
> beginner’s have to learn when inference is available when declaring their 
> types. That’s story is sketchy.
>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>> 
>> This is not really a helpful comment, but: I kinda wish they did.
>> 
>> l8r
>> Sean
>> 
>>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Neither of these works btw.
>>> 
>>> func bar(myString = “hello”)
>>> class Baz {
>>> let myString = { return “hello” }()
>>> }
>>> 
 On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
 
 I’m full -1 on this one. It will make the language inconsistent. How do 
 you explain a new comer that type inference work in some case, but not in 
 other cases, while in both the compiler is completely capable to define 
 the type.
 
 Why 
 
 let myString = "hello" 
 
 would be accepted but not 
 
 class Foo {
let myString = "hello" 
 }
 
 
 
> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>  a écrit :
> 
> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, 
>> Slava brought up some performance problems caused by type inference for 
>> stored properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. 
>> I think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, 
>> there're always the general benefit of making type declartion more 
>> explicit and readable (clarity for reader should out-weigh pleasure of 
>> the author). Making the
>> language slightly more consistent (we are not inferring types for 
>> default parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the 
>> language feels more friendly and is, undoubtedly, a beloved feature for 
>> many. This would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do 
>> y'all think?
>> 
>> Daniel Duan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

It is helpful in the sense that it tells us what’s really inconsistent: 
beginner’s have to learn when inference is available when declaring their 
types. That’s story is sketchy.
> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
> 
> This is not really a helpful comment, but: I kinda wish they did.
> 
> l8r
> Sean
> 
>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Neither of these works btw.
>> 
>> func bar(myString = “hello”)
>> class Baz {
>>  let myString = { return “hello” }()
>> }
>> 
>>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>>> 
>>> I’m full -1 on this one. It will make the language inconsistent. How do you 
>>> explain a new comer that type inference work in some case, but not in other 
>>> cases, while in both the compiler is completely capable to define the type.
>>> 
>>> Why 
>>> 
>>> let myString = "hello" 
>>> 
>>> would be accepted but not 
>>> 
>>> class Foo {
>>> let myString = "hello" 
>>> }
>>> 
>>> 
>>> 
 Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
  a écrit :
 
 I’m still not sure whether *I* want this. But here’s a proposal anyways: 
 https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
 
> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members 
> contemplated requiring types for stored properties in type declarations. 
> I think this idea deserves some more attention. Hence this last minute 
> idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). 
> Making the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do 
> y'all think?
> 
> Daniel Duan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

This is not really a helpful comment, but: I kinda wish they did.

l8r
Sean

> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Neither of these works btw.
> 
> func bar(myString = “hello”)
> class Baz {
>   let myString = { return “hello” }()
> }
> 
>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>> 
>> I’m full -1 on this one. It will make the language inconsistent. How do you 
>> explain a new comer that type inference work in some case, but not in other 
>> cases, while in both the compiler is completely capable to define the type.
>> 
>> Why 
>> 
>> let myString = "hello" 
>> 
>> would be accepted but not 
>> 
>> class Foo {
>>  let myString = "hello" 
>> }
>> 
>> 
>> 
>>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>>  a écrit :
>>> 
>>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Hi all,
 
 In a discussion about inferring parameter types from default value, Slava 
 brought up some performance problems caused by type inference for stored 
 properties in side types:
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 
 Towards the end, the post mentioned that some Swift team members 
 contemplated requiring types for stored properties in type declarations. I 
 think this idea deserves some more attention. Hence this last minute 
 idea-floating.
 
 In addition to solving a performance headache in implementation, there're 
 always the general benefit of making type declartion more explicit and 
 readable (clarity for reader should out-weigh pleasure of the author). 
 Making the
 language slightly more consistent (we are not inferring types for default 
 parameter values in function anyways).
 
 The cons for doing this are obvious too: the inference makes the language 
 feels more friendly and is, undoubtedly, a beloved feature for many. This 
 would be a source breaking change.
 
 Just thought I'd float the idea to gather some quick reaction. What do 
 y'all think?
 
 Daniel Duan
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

Neither of these works btw.

func bar(myString = “hello”)
class Baz {
  let myString = { return “hello” }()
}

> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How do you 
> explain a new comer that type inference work in some case, but not in other 
> cases, while in both the compiler is completely capable to define the type.
> 
> Why 
> 
> let myString = "hello" 
> 
> would be accepted but not 
> 
> class Foo {
>   let myString = "hello" 
> }
> 
> 
> 
>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 
>> 
>> 
>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> In a discussion about inferring parameter types from default value, Slava 
>>> brought up some performance problems caused by type inference for stored 
>>> properties in side types:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>>  
>>> 
>>> 
>>> Towards the end, the post mentioned that some Swift team members 
>>> contemplated requiring types for stored properties in type declarations. I 
>>> think this idea deserves some more attention. Hence this last minute 
>>> idea-floating.
>>> 
>>> In addition to solving a performance headache in implementation, there're 
>>> always the general benefit of making type declartion more explicit and 
>>> readable (clarity for reader should out-weigh pleasure of the author). 
>>> Making the
>>> language slightly more consistent (we are not inferring types for default 
>>> parameter values in function anyways).
>>> 
>>> The cons for doing this are obvious too: the inference makes the language 
>>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> would be a source breaking change.
>>> 
>>> Just thought I'd float the idea to gather some quick reaction. What do 
>>> y'all think?
>>> 
>>> Daniel Duan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> What do you think of `partial` types like C# but limited to a file?

Well, imho it would be better than some alternatives, because it might lay the 
ground for something that is more useful than current same-file extensions, 
which offer no guarantee that the extension declaring the conformance adds 
anything to fulfil them (and because of retroactive conformance, I don't think 
this will be changed for extensions).

If private isn't restricted to a single scope anymore, imho all the splitting 
has no practical benefits at all, and even if we keep the old definition, I 
doubt that it's worth the increased complexity:
A //MARK-comment is much more useful than an extension, and like many 
developers, I prefer to keep instance variables grouped in a prominent place 
(above the methods), so most likely wouldn't use the "special power" of partial.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 10:26 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> I’m not sure that this solves anything meaningful (whether in relation to 
>> SE-0169 or more generally), does it? What advantage does this provide over 
>> just declaring the protocol conformance and those methods as a direct part 
>> of the parent type? This seems like it would just introduce more 
>> indentation, and more lines of code, for zero benefit.
> Well, I'm not overwhelmingly convinced of this whole "we put same-module 
> stuff into extensions" anyways, so it's debatable wether proposals like 
> SE-0169 have any meaningful effects at all… do you think that conformances in 
> same-file extensions have a real benefit? 

I think the primary benefit is organizational.  People like having the members 
that implement a conformance grouped together with the conformance declaration.

> 
> If nothing else, nested extensions could save those who actually don't care 
> much about such issues from another breaking change in Swift — and imho it 
> adds consistency:
> We can nest types, so why can't we nest extensions?
> ___
> 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] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> I’m not sure that this solves anything meaningful (whether in relation to 
> SE-0169 or more generally), does it? What advantage does this provide over 
> just declaring the protocol conformance and those methods as a direct part of 
> the parent type? This seems like it would just introduce more indentation, 
> and more lines of code, for zero benefit.
Well, I'm not overwhelmingly convinced of this whole "we put same-module stuff 
into extensions" anyways, so it's debatable wether proposals like SE-0169 have 
any meaningful effects at all… do you think that conformances in same-file 
extensions have a real benefit? 

If nothing else, nested extensions could save those who actually don't care 
much about such issues from another breaking change in Swift — and imho it adds 
consistency:
We can nest types, so why can't we nest extensions?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

[Maximilian Hünenberger via swift-evolution]

How about this:

array.removeEvery(3)
array.removeEvery{ $0 > 3 }

I think it preserves the meaning while it reads nicely. However "every" has no 
precedent in other functions, as far as I know.

> Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution 
> :
> 
> 
>>> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon  
>>> wrote:
>>> 
>>> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> +1. Perfect. Let's not bikeshed this and get it done!
>> 
>> 
>> Sorry, I'm going to have to insist on bikeshedding.
>> 
>> `equalTo:` is kind of ugly and has no precedent in the standard library. 
>> Similar APIs seem to either leave the parameter unlabeled or use `of:` (as 
>> in `index(of:)`). I think unlabeled is probably the right answer here.
>> 
> 
> I think removeAll(of:) works well for the equatable value version.
> 
> FWIW of all the ideas from the all thread, containsOnly(_:) for the equatable 
> value version works for me. It has a nice symmetry: contains(3) vs 
> containsOnly(3).
> 
>> The main shortcoming I can see is that if you see:
>> 
>>  array.removeAll(3)
>> 
> 
> Personally don’t feel good about an unlabelled version. It doesn’t read 
> right. Remove all three what?
> 
>> You might think `3` is either an index or a count. But neither of those 
>> actually make sense:
>> 
>> * It can't be an index because then `All` would have no meaning. There's 
>> only ever one thing at a given index. Besides, indices are almost always 
>> marked with `at:` or another parameter label.
>> * It can't be a count because `All` is already a count. What could "remove 
>> all 3" possibly mean if the array doesn't happen to have three elements?
>> 
>> And this is only a problem if the value happens to be an integer. If it's 
>> anything else, the type makes clear that this can't possibly be an index or 
>> count; it must be an element.
>> 
>> (But if you really do think this is insurmountable, `removeAll(of: 3)` *is* 
>> impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)
>> 
>> (P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` 
>> and `removeAll()` is why I proposed last year that it be renamed to 
>> `removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> The one issue I see is sticking that public extension inside a private one.  
> I think you would have to mark ‘secret: Int’ as private instead of the 
> extension itself to allow the effect you are looking for…
I didn't think that much while writing the example, but this one was actually 
on purpose:
It's stated in the Swift documentation that the default visibility of members 
in an extension equals the level of the extension — so this use of extensions 
is also a way to group all public declarations (the other levels as well), and 
save some keystrokes.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato via swift-evolution]

Extensions can already do what partials would do, and more—Swift does not
need two features that are almost the same but with subtle differences when
it comes to the visibility of its members. That seems like something that
will only cause confusion for users. Partials feel like trying to shoehorn
a feature from another language into Swift to solve an unrelated problem.

Swift 2 and 3 have never had type-oriented visibility—they've only had
visibility that covered contiguous regions of the symbol space ("the
universe", "the module", "the file", and then in Swift 3, "the enclosing
scope"). Being able to split a type's *scope* with partials (as opposed to
just the type itself with extensions) across multiple files files would be
quite inconsistent with how visibility in Swift has been so far.

At some point, we need to come to grips with the fact that there are going
to be keywords we think are a little ugly (I much preferred the original
definition of "private", but "fileprivate" is part of Swift now and I've
moved on) and that there's never going to be a way to perfectly audit
visibility of every single member that we write in a way that makes
everyone happy.

I don't want to sound dismissive, but I feel like it's simply not
productive to keep rehashing visibility over and over again.


On Mon, Apr 10, 2017 at 7:20 AM Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
>
>
> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
>
> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This struck me as a bit odd at first, but the more I think about it, the
> more I really like the ability to nest extensions/scopes.  The one issue I
> see is sticking that public extension inside a private one.  I think you
> would have to mark ‘secret: Int’ as private instead of the extension itself
> to allow the effect you are looking for...
>
> What I ultimately want is the ability to declare storage in extensions in
> the same submodule. Combining that with fileprivate will allow the same
> tricks without the indentation (together in their own file).  This nesting
> will help in the mean-time (and would still be useful after for those who
> prefer to organize their code in fewer/longer files).  I think it could be
> helpful in other ways too…
>
>
> What do you think of `partial` types like C# but limited to a file?
> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>
>
> That's the direction the new proposal (0169) is going towards with
> extensions in the same file.
>
>
> I don’t see how SE-0169 do that more than any other meaning private got
> until now. This was already the case with the initial meaning of private,
> and was the case with fileprivate.
>
>
> The current semantics of private don’t give any support for partial types
> like in C# because the accessibility is restricted to the current scope.
> With SE-0169’s private, extensions in the same file as the type share that
> scope. Plus, the *Alternatives Considered* section of the proposal
> discusses potential future directions where those extensions could look
> even more like C# partials :)
>
>
> SE-169 could be emulated cleanly by introducing partial types within the *same
> scope* as a new feature completely separate from extensions. Partial
> types would not require redefining how private or extensions work now. It
> would also serve as a way to communicate to the user that the type is not
> done being defined so if they want to encapsulate the type completely, They
> have to make it non partial.
>
>
>
>
>
>
> And for file splitting and visibility control, we need submodules. Until
> then, if this proposal is to define the ultimate meaning of private, I
> rather like this meaning that the SE-0025 one.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
>>> 
>>> 
>>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>>>  a écrit :
>>> 
>>> 
>>> 
>>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>>>  wrote:
>>> 
 
> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> This struck me as a bit odd at first, but the more I think about it, the 
> more I really like the ability to nest extensions/scopes.  The one issue 
> I see is sticking that public extension inside a private one.  I think 
> you would have to mark ‘secret: Int’ as private instead of the extension 
> itself to allow the effect you are looking for...
> 
> What I ultimately want is the ability to declare storage in extensions in 
> the same submodule. Combining that with fileprivate will allow the same 
> tricks without the indentation (together in their own file).  This 
> nesting will help in the mean-time (and would still be useful after for 
> those who prefer to organize their code in fewer/longer files).  I think 
> it could be helpful in other ways too…
 
 What do you think of `partial` types like C# but limited to a file?
 https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
 
>>> 
>>> That's the direction the new proposal (0169) is going towards with 
>>> extensions in the same file.
>> 
>> I don’t see how SE-0169 do that more than any other meaning private got 
>> until now. This was already the case with the initial meaning of private, 
>> and was the case with fileprivate.
> 
> The current semantics of private don’t give any support for partial types 
> like in C# because the accessibility is restricted to the current scope. With 
> SE-0169’s private, extensions in the same file as the type share that scope. 
> Plus, the Alternatives Considered section of the proposal discusses potential 
> future directions where those extensions could look even more like C# 
> partials :)

SE-169 could be emulated cleanly by introducing partial types within the same 
scope as a new feature completely separate from extensions. Partial types would 
not require redefining how private or extensions work now. It would also serve 
as a way to communicate to the user that the type is not done being defined so 
if they want to encapsulate the type completely, They have to make it non 
partial. 





> 
>> And for file splitting and visibility control, we need submodules. Until 
>> then, if this proposal is to define the ultimate meaning of private, I 
>> rather like this meaning that the SE-0025 one.
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

[Marco Masser via swift-evolution]

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
 



I’m not giving a complete review here, but this proposal seems like a fantastic 
solution to me.
There’s one thing I either missed or that is actually missing that I would like 
to discuss.

NSObject defines the following method:
func awakeAfter(using aDecoder: NSCoder) -> Any?

I can find no discussion in the proposal about the intended replacement for the 
functionality this method provides. This method probably counts to the more 
obscure parts of Foundation and is probably almost never implemented. But 
there’s a use case in the code base I’m working on and I would like to discuss 
the intended replacement mechanism for it in the context of this proposal.

We have an Objective-C class that represents a single DNS name (e.g. a host 
name or a domain name). Instances are cached so whenever such an object is 
created (for e.g. “apple.com”), the same instance is returned (this is done 
using factory methods).
These DNS name objects are also encoded using NSCoding (for distributed object 
calls and for archiving to disk) and when decoding them, the same instance is 
returned every time. The decoding mechanism cannot take care of this because it 
cannot know whether such an instance exists already (created by a previous call 
to the aforementioned factory method). Using awakeAfter(using:) provides this 
functionality by looking up the cache and returning the already existing 
instance.

I suspect that the replacement for such a use case in Swift are structs and 
value types where there is no concept of identity. I would like to know if that 
is the answer the proposal author would give or if I’m missing something.


Similarly, I can’t find a replacement for the functionality following method of 
NSObject:
- (nullable id)replacementObjectForCoder:(NSCoder *)aCoder;

… but I think this is only used for DO calls and proxy objects and the intended 
replacement is XPC.


Regards,

Marco



> On 2017-04-06, at 20:10, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Thorsten Seitz via swift-evolution]

> Am 09.04.2017 um 18:29 schrieb John Holdsworth :
> 
> Hi, John here, the submitter of the proposal.
> 
> First up, I must apologise for putting Brent on the spot when I resubmitted 
> this altered proposal from last year. That was my mistake.
> 
> Second up, apologies if the proposal is rather vague on details. In some 
> sense this was intentional as I didn’t want to get too bogged down in 
> specifics (and not at all to do with my limitations as a technical writer!)
> 
> I guess we need to build up consensus more slowly by asking the following 
> questions separately so it can be resubmitted rather than giving a binary 
> +/-1 on the proposal as it stands.
> 
> 1) Does Swift need multi-line string literals?

Yes.

> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
> precise delimiter

Yes.

> 3) Is the “magic" leading whitespace removal a good idea to support 
> indentation.

Yes.

> 4) Does the proposal contain sufficient detail to be discussed/implemented

Thanks for the update! I only have the following issues left:

> All other escapes would be processed as before including interpolation, \n 
> and "
You probably meant \“ instead of " here.

The proposal should state what kind of newline will be used within a multiline 
string literal. I already proposed that it should be exactly the same as for \n 
and not the newline character(s) actually used in the file (e.g. LF+CR or LF or 
CR), to avoid issues when working on different platforms (Windows, Mac, Linux) 
and/or using Git’s autocrlf feature.

The proposal should give an example how to create a multiline string literal 
which ends with a newline (AFAIU there should be an empty line before the 
closing ""“).

-Thorsten

> 
> My answer to 1) is obviously yes and I think the discussion has come out 
> about 50/50 so far so lets persevere...
> 
> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long 
> string”_ or #”long string”# is a string literal inside a new delimiter. It 
> would be processed exactly as it would a normal string including escapes and 
> interpolation except the string can include unescaped “ or  “" and newlines. 
> Also, a \ at the end of the line would mean that particular newline is not 
> included in the string.
> 
> For me, the goals of a long string are that it should be able to pasted in 
> (almost) without modification from a text source and that syntax highlighting 
> would work for the widest possible range of text editors and github. “””long 
> string””” is just a trick Python uses to satisfy the second goal (for example 
> this gist 
> )
>  but highlighting also works for asymmetric delimiters such as @“long 
> string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty 
> #equivalent does not satisfy this second goal at all well and IMHO it should 
> be excluded. It would also be significantly more difficult to integrate into 
> the Swift compiler.
> 
> Looking at 3) which is underspecified in the proposal perhaps, I’d consider 
> it a “feature" but I can see it would be too magical for some. To specify it 
> more you could say: if there is only whitespace between the last newline and 
> the end of a multiline literal this whitespace will be stripped from all 
> lines in the literal. If lines do not start with this exact sequence of 
> whitespace a warning is emitted. In addition, if the first character in the 
> literal is a newline it will be removed. This operation could be made 
> explicit e.g. #trimLeft(“”"a literal""")
> 
> Perhaps we can find common ground on 1) and 2) and even 3) with a view to 
> resubmitting if there is time. Seems mostly like we just need to discuss the 
> delimiter further and decide whether the indent trimming is a bug or a 
> feature to keep moving and not let another year slip by.
> 
> With respect to 4) I’m updating 
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
>  as the proposal is discussed to fill in some of the gaps & I’ve prepared a 
> toolchain for Swift 3 if you want to try an implementation out  
> 
> 
>> On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>>>  
>>> 
>>> What is your evaluation of the proposal?
>> 
>> +1
>> 
>> My foremost expectation from multiline string literals is to be able to copy 
>> and paste multiline string literals without having to fiddle with escape 
>> marks or leading and trailing quotes or continuation char

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

I think it would be good to clarify that there are two similar things we 
discuss in this proposal.

This proposal is about a [(multi-line string) literal].

And there is also the [multi-line (string literal)].

These are two different things because (1) does add explicit escaping for some 
characters, where (2) is the current string literal extended for multilines.

As I already mentioned in my previous post, personally I’m in favor of (2) and 
the existence of (2) raises the question if we need (1) for implicit escaping 
at all, which I personally like to compare with laziness.

The existence of (2) is easier from the writers perspective, because if you 
decide at some point to break up your string into multi lines, the string 
itself won’t be altered because there is no implicit character added to the 
string, and indent would work as you’d expect it to work. If one would need 
more precision there would exist leading and trailing precision characters.

However, I think it might be really good compromise, at least to me, as someone 
mentioned in this review, that we could add a backslash to the proposed (1) 
[(multi-line string) literal] to prevent implicit new lines and at the same 
time add trailing precision.

Final words, if I had to choose between (1) and (2), I’d go with (2), because I 
don’t like the optimization magic that happens behind the scene and would 
prefer a concrete model for a string literal.



-- 
Adrian Zubarev
Sent with Airmail

Am 10. April 2017 um 04:44:15, Brent Royal-Gordon via swift-evolution 
(swift-evolution@swift.org) schrieb:

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution 
 wrote:

Perhaps we can find common ground on 1) and 2) and even 3) with a view to 
resubmitting if there is time. Seems mostly like we just need to discuss the 
delimiter further and decide whether the indent trimming is a bug or a feature 
to keep moving and not let another year slip by.

Honestly, I think this is a little premature. If I had to summarize this 
thread, I think what I'm seeing is:

1. We wish the proposal were more specific on a few points, like the 
de-indenting algorithm.

2. We have lots of different pet syntaxes and preferences.

3. But most of us are still in favor of accepting the proposal.

To back up that last point, I ran through the thread and tried to quickly 
figure out what everyone was thinking. These people seem to be opposed to the 
proposal: 

1. Haravikk doesn't like the de-indenting and seems iffy on multiline strings 
in general.
2. David Waite wants a suite of different, orthogonal string literal features 
to get enough flexibility.
3. Félix Cloutier is worried that supporting interpolation makes this feature a 
powerful footgun.
4. Adrian Zubarev wants to extend single-quoted string literals instead of 
developing a second syntax.

These people want the proposal to be more specific, but appear to be in favor 
as long as the missing details don't reveal problems:

1. Greg Parker (maybe?)
2. Xiaodi Wu
3. Gwendel Roué

And these people all seem basically positive, though sometimes with 
reservations or bikeshedding suggestions:

1. Me
2. Tony Allevato
3. David Hart
4. Daniel Duan
5. Ricardo Parada
6. Kevin Nattinger
7. Víctor Pimentel Rodríguez
8. Jarod Long (I think)
9. Ben Cohen
10. Thorsten Seitz
11. Howard Lovatt
12. T.J. Usiyan

Evolution reviews are not referenda, but I think it's fair to say that the 
sentiment is mostly positive.

(And if the core team does say they like the approach but want clarifications, 
I'd be happy to pitch in and earn the co-author credit!)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[David Hart via swift-evolution]

> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>  wrote:
> 
> This is a really great proposal. As an iOS developer I work with JSON almost 
> every day since most mobile apps communicate with a backend through JSON 
> messages. It's good to see that better JSON support is coming to Foundation 
> so we don't have to rely on third party libraries.
> 
> That being said, there is one thing I don't like which is that the JSON 
> encoding function returns Data and the decoding function takes Data.
> 
> It would be really great if the Foundation team could introduce a dedicated 
> type of JSON.
> There are several advantages of working with a dedicated type.
> - The underlying data is always valid JSON
> - You can extend this type in the future with helper methods for manipulating 
> JSON
> - It makes it explicit what you are dealing with
> 
> A good analogy is the URL type. You could represent an URL with a String or 
> Data type, but by introducing a dedicated type you have the full advantages 
> mentioned above. Data on the other hand is like a generic container which you 
> cannot easily extend with URL or JSON specific methods.
> 
> Having a dedicated JSON type is also one of the reasons third party libraries 
> like SwiftyJSON are so popular. It makes it super easy to manipulate JSON 
> structures. And sometimes developers like would like to manipulate JSON 
> directly.

I don’t think it would be a good thing to have this in Foundation. Foundation 
needs to push developers towards adopting best practices, and manipulating JSON 
directly instead of going through Codable’s strong-typing is not necessarily 
recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is 
definitely narrow now once we have Codable. I think this is something that 
should stay in a third-party library.

> If the proposal would pass in the current form, I would still use SwiftyJSON 
> for manipulating JSON which I would rather avoid and have this all sorted on 
> the Foundation level.
> 
> Just my two cents from the perspective of an iOS developer. JSON handling is 
> really important to us so I hope you make it great!
> 
> 
> Hello Swift community,
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Note that this proposal is closely related to (and dependent on) SE-0166: 
> Swift Archival & Serialization 
>   
> >.
>  Please read and review that proposal as well!
> 
> 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/0167-swift-encoders.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
> _

[swift-evolution] [Review] SE-0167: Swift Encoders

[piotr gorzelany via swift-evolution]

This is a really great proposal. As an iOS developer I work with JSON
almost every day since most mobile apps communicate with a backend through
JSON messages. It's good to see that better JSON support is coming to
Foundation so we don't have to rely on third party libraries.

That being said, there is one thing I don't like which is that the JSON
encoding function returns Data and the decoding function takes Data.

It would be really great if the Foundation team could introduce a dedicated
type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for
manipulating JSON
- It makes it explicit what you are dealing with

A good analogy is the URL type. You could represent an URL with a String or
Data type, but by introducing a dedicated type you have the full advantages
mentioned above. Data on the other hand is like a generic container which
you cannot easily extend with URL or JSON specific methods.

Having a dedicated JSON type is also one of the reasons third party
libraries like SwiftyJSON are so popular. It makes it super easy to
manipulate JSON structures. And sometimes developers like would like to
manipulate JSON directly.

If the proposal would pass in the current form, I would still use
SwiftyJSON for manipulating JSON which I would rather avoid and have this
all sorted on the Foundation level.

Just my two cents from the perspective of an iOS developer. JSON handling
is really important to us so I hope you make it great!



Hello Swift community,

The review of SE-0167 "Swift Encoders" begins now and runs through
April 12, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Note that this proposal is closely related to (and dependent on)
SE-0166: Swift Archival & Serialization
.
Please read and review that proposal as well!

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/0167-swift-encoders.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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Karl Wagner via swift-evolution]

> On 9 Apr 2017, at 19:36, Tino Heth via swift-evolution 
>  wrote:
> 
> -1:
> Although prefix "\" is imho the nicest variation that has been officially 
> suggested for this feature (I still like infix ":" better; maybe I've been 
> using classic MacOS to long), there is no general agreement, and many people 
> that voted "+1" did so despite preferring a different syntax, just because 
> they want to have the feature asap.
> 
> But haste is a bad counsellor, and if we learned anything from the disaster 
> of "new private", we shouldn't rush and constitute how an obviously important 
> (or at least popular) feature should look like without taking into account 
> the big picture:
> KeyPaths are at least entwined with method references and reflection, so 
> until we have a concrete idea of those ties, no narrow proposal should be 
> implemented*.
> 
> - Tino
> 
> * preliminary acceptance with delayed implementation would be fine for me — I 
> just don't want to paint ourselves into a corner...
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Or the other way around - if its implementable right now, we should do it and 
gather feedback on the syntax in real usage. I think we’re all agreed on the 
functionality.

Personally, I’d like to see these smart KeyPaths become more of a first-class 
language feature. We should define a new family of operators to use with them, 
instead of named methods. The “::” member reference operator (on a type, 
returning a keypath, or on a keypath, returning a sub-keypath) could be one.

Subscripting: replace with arrow (indirect access) operator. Parallels the dot 
operator for direct access. “Indirect” here means the keypath, since it may be 
invalid for this object and return nil (depending on which keypath you provide).

let name = luke->firstFriendNameKeyPath // “Han Solo"
let name = luke->friends[0]::name // Equivalent to luke.friends[0].name

Appending: replace with backslash operator.

let personName = Person::name
let nameToFind = luke->personName // “Luke Skywalker”
for p in people {
   if p->friends[0]\personName == nameToFind { return p }
}

If you are directly entering a keypath, we could infer the type for the :: 
operator, so you could just directly type members in. That’s fine - if you’re 
accessing a known member on a known type, even by keypath, “->" will get 
optimised in to a direct access anyway.

let name = AnyKeyPath(Person::name)
for p in people {
if let n = p->friends[0]\name, n == nameToFind { return p }
}

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

[swift-evolution] [Pitch?] Add clamp(to:) to the stdlib

[Nicholas Maccharoli via swift-evolution]

Swift-Evolution,

I was wondering if there was still some support from the community for
adding `clamped(to:)` extensions to `Strideable` and `Comparable` for
clamping a value on a provided range.

The proposal is detailed below, sorry if I skipped a step earlier.

Also here is a link to the pull request I sent on Github to the
Swift-Evolution repository:

https://github.com/apple/swift-evolution/pull/641

All the best,

- Nick



Add clamp(to:) to the stdlib

   - Proposal: SE-
   

   - Authors: Nicholas Maccharoli 
   - Review Manager: TBD
   - Status: Awaiting review

*During the review process, add the following fields as needed:*

   - Decision Notes: Rationale
   , Additional
   Commentary 
   - Bugs: SR- , SR-
   
   - Previous Revision: 1
   

   - Previous Proposal: SE-
   



Introduction

This proposal aims to add functionality to the standard library for
clamping a value to a provided Range. The proposed function would allow the
user to specify a range to clamp a value to where if the value fell within
the range, the value would be returned as is, if the value being clamped
exceeded the upper or lower bound in value the value of the boundary the
value exceeded would be returned.

Swift-evolution thread: Add a clamp function to Algorithm.swift


Motivation

There have been quite a few times in my professional and personal
programming life where I reached for a function to limit a value to a given
range and was disappointed it was not part of the standard library.

There already exists an extension to CountableRange in the standard library
implementing clamped(to:) that will limit the calling range to that of the
provided range, so having the same functionality but just for types that
conform to the Comparable protocol would be conceptually consistent.

Having functionality like clamped(to:) added to Comparable as a protocol
extension would benefit users of the Swift language who wish to guarantee
that a value is kept within bounds, perhaps one example of this coming in
handy would be to limit the result of some calculation between two
acceptable numerical limits, say the bounds of a coordinate system.
Proposed
solution

The proposed solution is to add a clamped(to:) function to the Swift
Standard Library as an extension to Comparable and Strideable. The function
would return a value within the bounds of the provided range, if the value
clamped(to:) is being called on falls within the provided range then the
original value would be returned. If the value was less or greater than the
bounds of the provided range then the respective lower or upper bound of
the range would be returned.

It does not make sense to call clamped(to:) with an empty range, therefore
calling clamped(to:) and passing an empty range like foo.clamped(to:
0..<0) would
result in a fatal error.

Given a clamped(to:) function existed it could be called in the following
way, yielding the results in the adjacent comments:

let foo = 100
// Closed range variant
foo.clamped(to: 0...50) // 50foo.clamped(to: 200...300) //
200foo.clamped(to: 0...150) // 100// Half-Open range variant
foo.clamped(to: 0..<50) // 49foo.clamped(to: 200..<300) //
200foo.clamped(to: 0..<150) // 100

Detailed
design

The implementation of clamped(to:) that is being proposed is composed of
two protocol extensions; one protocol extension on Comparable and another
on Strideable.

The implementation for clamped(to:) as an extension to Comparable accepting
a range of type ClosedRangewould look like the following:

extension Comparable {
func clamped(to range: ClosedRange) -> Self {
if self > range.upperBound {
return range.upperBound
} else if self < range.lowerBound {
return range.lowerBound
} else {
return self
}
}
}

T

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
> 
> 
>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> 
>> 
>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 This struck me as a bit odd at first, but the more I think about it, the 
 more I really like the ability to nest extensions/scopes.  The one issue I 
 see is sticking that public extension inside a private one.  I think you 
 would have to mark ‘secret: Int’ as private instead of the extension 
 itself to allow the effect you are looking for...
 
 What I ultimately want is the ability to declare storage in extensions in 
 the same submodule. Combining that with fileprivate will allow the same 
 tricks without the indentation (together in their own file).  This nesting 
 will help in the mean-time (and would still be useful after for those who 
 prefer to organize their code in fewer/longer files).  I think it could be 
 helpful in other ways too…
>>> 
>>> What do you think of `partial` types like C# but limited to a file?
>>> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx 
>>> 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>>>  
>>> 
>>> 
>> 
>> That's the direction the new proposal (0169) is going towards with 
>> extensions in the same file.
> 
> I don’t see how SE-0169 do that more than any other meaning private got until 
> now. This was already the case with the initial meaning of private, and was 
> the case with fileprivate.

The current semantics of private don’t give any support for partial types like 
in C# because the accessibility is restricted to the current scope. With 
SE-0169’s private, extensions in the same file as the type share that scope. 
Plus, the Alternatives Considered section of the proposal discusses potential 
future directions where those extensions could look even more like C# partials 
:)

> And for file splitting and visibility control, we need submodules. Until 
> then, if this proposal is to define the ultimate meaning of private, I rather 
> like this meaning that the SE-0025 one.
> 

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