Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

Hi Jay,

> On Oct 16, 2016, at 7:14 PM, Jay Abbott  wrote:
> 
> 
> I like the core idea here, but I feel that it could potentially prevent teams 
> updating, through focus on other things and general laziness/ignorance to 
> what's going on with external dependencies. Although this gives me a separate 
> idea...

I hope to tackle this through features which will help notify you when new 
versions you could upgrade to are available. I hope the default practice in the 
ecosystem will then become to heed those notifications and update.

> How about an additional feature that can be run manually if desired, or more 
> likely run as a daily/overnight job on CI. I'm not entirely sure what the 
> command would be or how it would work exactly, but the general idea would be:
> 
> * Build a list of dependencies that can potentially be updated (from the 
> entire dependency graph).
> * For each updatable dependency in the list {
> * Keep all the other pins as-they-were and fetch the updated dependency.
> * Build the project and run its tests.
> * Keep track of which ones worked and which ones failed.
> }
> * If there are updatable dependencies that build successfully, and all (your 
> project) tests still pass - this can to be reported to the development team.
> 
> This way, teams could use pinning and automate checking for compatible 
> updates. Also package owners could potentially be notified (with explicit 
> consent of their users) if they broke compatibility in what should have been 
> a compatible release. I realise that not everything going on here is inside 
> the remit of a package manager, but the package manager could provide 
> functionality to help with such things, a bit like git-bisect. Then again, 
> the SPM community proposal seems to cast quite a wide potential remit.
> 
> An additional cool feature would be some mechanism to allow notifications to 
> the package owner if what they have released as compatible (according to the 
> version) actually isn't. Explicit opt-in from users for this one of course, 
> with options for what information to include. Maybe swift.org 
>  could host this for package owners, and usage stats for 
> them too?

Both of the features you propose make a lot of sense to me, and are things I 
definitely would like to see us do in time.

For now, though, I see this feature as a "building block" towards those 
directions. Others can build on top of this feature to create automated systems 
like the ones you describe, I don't think we need to try and tackle everything 
ourselves in the initial proposal.

 - Daniel

> 
> On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution 
> > wrote:
> > In Swift, we have pretty consistently tried to choose the "right" answer to 
> > make the resulting language consistent and beautiful.
> > I'm perfectly happy to have a discussion about the naming, but I would like 
> > it to be driven by what we believe the "right" answer is, not simply by 
> > deference to existing solutions.
> 
> +100
> 
> Moreover, after your explanation, `lock` feels wrong to me too.
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[Jonathan Hull via swift-evolution]

> On Oct 16, 2016, at 7:23 PM, Xiaodi Wu  wrote:
> 
> On that last point, I would push back against calling it access inflation. If 
> a member needs to be visible outside the file for whatever reason, it needs 
> to have at least internal visibility. This is not at all "inflated" (implying 
> that it's a workaround) but an explicitly contemplated part of Swift's access 
> scheme.
But what happens when someone needs to make an extension outside of the module? 
 For example, subclassing UIGestureRecognizer.  Should things like setState: 
(which triggers a bunch of side effects and should never be called externally) 
be made public?  The only two options in pure Swift 3 (it only gains it’s 
protected-style import from ObjC) are to make them public or to disallow 
subclassing outside the module (you have to call setState: as part of 
implementing a custom gesture recognizer).


> What you're arguing is that we should be able to expressly enumerate the 
> specific files in which a member is accessible. This is a more granular 
> system, but increased granularity is not in and of itself sufficient 
> justification. After all, if more granularity is better--and this is an 
> argumentum ad absurdum--why not demand that we be able to expressly enumerate 
> the specific types that can access that member? why not the specific methods 
> of those types? why not the specific scope? why not the specific line?
Actually, I am arguing almost the opposite.  I had originally wanted a more 
granular system like 'protected’ from most languages.  This proposal comes from 
a realization that file granularity is most likely good enough for real world 
use cases.

What I am arguing is important:
1) The author’s ability to show which items should generally not be 
accessible/used, but are still provided/required for extension/subclassing 
purposes.
2) Requiring users of these items to acknowledge the author’s intent (by 
requiring ‘import hidden’) before using them
3) Terminology which has the correct connotation for this new behavior


> It's all about what use cases are enabled or not at different points along 
> this spectrum of granularity. So the question is, does your proposed scheme 
> enable additional use cases that `internal` does not?
It allows use of ‘hidden’ variables/functions from other modules.  It also 
allows the author to show their intention that the variable/function is meant 
to be accessed elsewhere if needed for extension (vs. internal which is the 
default)… and it requires the user to acknowledge that intention.


> I'm not convinced that having access to a member at a use site when the 
> declaration itself is totally under your own control, in the same module, is 
> "brittle" is any meaningful sense.
What I mean by brittle is how much a change in one spot will ripple throughout 
your code by requiring other changes.  It becomes a much larger issue when 
multiple people are working on a code base.


Thanks,
Jon

> On Mon, Oct 17, 2016 at 09:51 Jonathan Hull via swift-evolution 
> > wrote:
> To put it more forcefully, I believe that ‘fileprivate’ currently suffers 
> from the same problem that singletons do.  That is, the main reason to make 
> something ‘fileprivate’ instead of ‘private’ is to allow some sort of 
> extension.  It is highly unlikely that the point you were required to expose 
> for that extension will not also be needed by other extensions.  Both 
> ‘internal’ and submodules would extend the boundaries of the problem from the 
> file boundary to the module/submodule boundary… but the underlying problem 
> still persists.
> 
> If it is the module designer’s intent to limit extension, then fine, but it 
> also often forces a design to be much more brittle and fragile than it needs 
> to be.  One of two things happens: extension becomes impossible or there is 
> access inflation, giving inappropriate levels of access (usually combined 
> with a note in the documentation saying not to use it).
> 
> Thanks,
> Jon
> 
> 
> 
>> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan > > wrote:
>> 
> 
>> I don't like this at all and it comes down to  "what is hidden can also be 
>> unhidden". This, to me, feels like it would create more confusion than it 
>> would address. Why not just use `internal` for `hidden` items?  If we're ok 
>> with modifying import statements, why not simply have a command that imports 
>> `fileprivate` stuff? (not advocating for this).
>> 
>> I think that submodules would have really helped with this issue and it is 
>> unfortunate that we couldn't get them in for swift 3. 
>> 
>> On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> I keep wanting a “protected” access level, but I must also admit that there 
>> was something really elegant about Swift 2’s 

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jonathan Hull via swift-evolution]

To put it more forcefully, I believe that ‘fileprivate’ currently suffers from 
the same problem that singletons do.  That is, the main reason to make 
something ‘fileprivate’ instead of ‘private’ is to allow some sort of 
extension.  It is highly unlikely that the point you were required to expose 
for that extension will not also be needed by other extensions.  Both 
‘internal’ and submodules would extend the boundaries of the problem from the 
file boundary to the module/submodule boundary… but the underlying problem 
still persists.

If it is the module designer’s intent to limit extension, then fine, but it 
also often forces a design to be much more brittle and fragile than it needs to 
be.  One of two things happens: extension becomes impossible or there is access 
inflation, giving inappropriate levels of access (usually combined with a note 
in the documentation saying not to use it).

Thanks,
Jon


> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan  wrote:
> 
> I don't like this at all and it comes down to  "what is hidden can also be 
> unhidden". This, to me, feels like it would create more confusion than it 
> would address. Why not just use `internal` for `hidden` items?  If we're ok 
> with modifying import statements, why not simply have a command that imports 
> `fileprivate` stuff? (not advocating for this).
> 
> I think that submodules would have really helped with this issue and it is 
> unfortunate that we couldn't get them in for swift 3. 
> 
> On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I keep wanting a “protected” access level, but I must also admit that there 
> was something really elegant about Swift 2’s access scheme (and I think most 
> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
> about how to mesh those two ideas, and I think I may have come up with a 
> solution.
> 
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
> would work exactly the same way as fileprivate does now, but adds the 
> connotation that what is hidden can also be unhidden.  By adding ‘import 
> hidden TypeName’ to another file, that file also gains access to all of the 
> hidden items of that type (kind of like if it was in the same file).
> 
> #FileA
> import Foundation
> 
> Struct A {
> private var x:Int
> hidden var y:Int  //This is just like fileprivate, but can 
> also be shared with other files
> }
> 
> extension A {
> //y can be accessed here because they are in the same file
> }
> 
> 
> #FileB
> import Foundation
> import hidden A  //This allows the entire file to see A’s hidden 
> variables
> 
> extension A {
> //y can be accessed here because of the ‘import hidden’ 
> declaration
> }
> 
> 
> #FileC
> import Foundation
> 
> extension A {
> //y can NOT be seen or accessed here because it is hidden
> }
> 
> 
> I think this is a fairly elegant solution to our protected dilemma, which 
> also feels in sync with Swift 2’s file-based scheme.  The key features:
> • Extensions no longer need to be piled in the same file if it is 
> getting too long
> • Subclasses can be in their own file, but still have access to the 
> necessary parts of their superclass
> • It communicates the author’s intent that the items are not meant to 
> be visible to its users, but that it is expected to be used for 
> extension/subclassing
> • It requires an explicit statement ‘import hidden’ to access the 
> hidden variables. Safe by default, with override.
> • It is not bound by module boundaries  (i.e. you could use it for 
> subclassing classes from an imported module)
> • Roughly the same length as ‘private’ and ‘public’ so various 
> declarations packed together are much easier to read (fileprivate breaks 
> reading rhythm)
> 
> Worth a formal proposal?
> 
> Thanks,
> Jon
> 
> 
> 
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[Xiaodi Wu via swift-evolution]

No need to rename fileprivate; it's irrelevant to your use case and is
resurrecting a bikeshedding discussion that really needs to be put to rest.

The proposal is essentially for something like @testable for fileprivate
members. Sounds fine to me.
On Mon, Oct 17, 2016 at 09:35 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan  wrote:
>
> I don't like this at all and it comes down to  "what is hidden can also
> be unhidden". This, to me, feels like it would create more confusion than
> it would address.
>
> I don’t think it would cause confusion. Other languages have things like
> protected, which is currently a glaring hole in Swift’s access control.
> This addresses that without any of the complexity of friend classes, etc….
>
>
> Why not just use `internal` for `hidden` items?
>
> Because there is an important aspect of communicating the author’s intent.
>
> I think it is important to be able to mark things which are not meant to
> be public (and internal is essentially public in the main module), but may
> be required by extensions/subclasses. With internal, it would be easy to
> accidentally create tightly coupled structures.  With ‘hidden', it requires
> intentional annotation (via the ‘include hidden’ statement) to gain access,
> so more thought will be given to the coupling.
>
> Also, internal would prevent extensions/subclasses outside the defining
> module.  With ‘hidden’ you have an author approved way of extending a type
> (even from another module).  I can’t actually think of a single use of
> ‘fileprivate’ where my intent/need was something other than allowing
> extensions. Unfortunately, with the current model those files can get quite
> a bit bigger than is ideal from an organizational standpoint.
>
>
> If we're ok with modifying import statements, why not simply have a
> command that imports `fileprivate` stuff? (not advocating for this).
>
> From a technical perspective, that is essentially what I am proposing, but
> terminology matters.  The word fileprivate was chosen to convey that the
> associated item was private to scope of the file. With this, we need to
> convey a slightly different intent because, while it does open access at
> file granularity, it is no longer private to the scope of that single file,
> and the name would be misleading.
>
> It doesn’t need to be the word ‘hidden’ necessarily, but it should be
> something with the correct connotation for the new behavior.
>
>
> I think that submodules would have really helped with this issue and it is
> unfortunate that we couldn't get them in for swift 3.
>
> I also want submodules, but they won’t fully solve the protected problem
> above.  They would allow you to group KNOWN subclasses and extensions into
> a single submodule.  But they would also prevent further extensions and
> subclasses from being made by the consumer of that module.  If that is what
> you want, then submodules are the answer, but there are also lots of cases
> where an author wants to allow careful subclassing outside of the original
> module.
>
> A good example of this is UIGestureRecognizer, which separates its
> protected items into a different include.  It hides all of the dangerous
> properties/methods in that separate file, and 98% of the time you don’t
> need it.  However, if you want to create your own gesture recognizer, you
> can’t really do it without those dangerous methods… thus you include the
> file.  With the submodule approach, you would either be unable to create
> your own gesture recognizer subclasses or the dangerous methods would be
> made available inappropriately.
>
>
> Thanks,
> Jon
>
>
> On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I keep wanting a “protected” access level, but I must also admit that
> there was something really elegant about Swift 2’s access scheme (and I
> think most of us feel like the word ‘fileprivate’ feels out of place).  I
> was thinking about how to mesh those two ideas, and I think I may have come
> up with a solution.
>
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.
> Hidden would work exactly the same way as fileprivate does now, but adds
> the connotation that what is hidden can also be unhidden.  By adding
> ‘import hidden TypeName’ to another file, that file also gains access to
> all of the hidden items of that type (kind of like if it was in the same
> file).
>
> #FileA
> import Foundation
>
> Struct A {
> private var x:Int
> hidden var y:Int  //This is just like fileprivate, but can
> also be shared with other files
> }
>
> extension A {
> //y can be accessed here because they are in the same file
> }
>
>
> #FileB
> import Foundation
> import hidden A  //This allows the entire file to see A’s hidden
> variables
>
> 

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Jonathan Hull via swift-evolution]

> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan  wrote:
> 
> I don't like this at all and it comes down to  "what is hidden can also be 
> unhidden". This, to me, feels like it would create more confusion than it 
> would address.
I don’t think it would cause confusion. Other languages have things like 
protected, which is currently a glaring hole in Swift’s access control. This 
addresses that without any of the complexity of friend classes, etc….


> Why not just use `internal` for `hidden` items? 
Because there is an important aspect of communicating the author’s intent. 

I think it is important to be able to mark things which are not meant to be 
public (and internal is essentially public in the main module), but may be 
required by extensions/subclasses. With internal, it would be easy to 
accidentally create tightly coupled structures.  With ‘hidden', it requires 
intentional annotation (via the ‘include hidden’ statement) to gain access, so 
more thought will be given to the coupling.

Also, internal would prevent extensions/subclasses outside the defining module. 
 With ‘hidden’ you have an author approved way of extending a type (even from 
another module).  I can’t actually think of a single use of ‘fileprivate’ where 
my intent/need was something other than allowing extensions. Unfortunately, 
with the current model those files can get quite a bit bigger than is ideal 
from an organizational standpoint.


> If we're ok with modifying import statements, why not simply have a command 
> that imports `fileprivate` stuff? (not advocating for this).
>From a technical perspective, that is essentially what I am proposing, but 
>terminology matters.  The word fileprivate was chosen to convey that the 
>associated item was private to scope of the file. With this, we need to convey 
>a slightly different intent because, while it does open access at file 
>granularity, it is no longer private to the scope of that single file, and the 
>name would be misleading.

It doesn’t need to be the word ‘hidden’ necessarily, but it should be something 
with the correct connotation for the new behavior.


> I think that submodules would have really helped with this issue and it is 
> unfortunate that we couldn't get them in for swift 3. 
I also want submodules, but they won’t fully solve the protected problem above. 
 They would allow you to group KNOWN subclasses and extensions into a single 
submodule.  But they would also prevent further extensions and subclasses from 
being made by the consumer of that module.  If that is what you want, then 
submodules are the answer, but there are also lots of cases where an author 
wants to allow careful subclassing outside of the original module.  

A good example of this is UIGestureRecognizer, which separates its protected 
items into a different include.  It hides all of the dangerous 
properties/methods in that separate file, and 98% of the time you don’t need 
it.  However, if you want to create your own gesture recognizer, you can’t 
really do it without those dangerous methods… thus you include the file.  With 
the submodule approach, you would either be unable to create your own gesture 
recognizer subclasses or the dangerous methods would be made available 
inappropriately.


Thanks,
Jon


> On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I keep wanting a “protected” access level, but I must also admit that there 
> was something really elegant about Swift 2’s access scheme (and I think most 
> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
> about how to mesh those two ideas, and I think I may have come up with a 
> solution.
> 
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
> would work exactly the same way as fileprivate does now, but adds the 
> connotation that what is hidden can also be unhidden.  By adding ‘import 
> hidden TypeName’ to another file, that file also gains access to all of the 
> hidden items of that type (kind of like if it was in the same file).
> 
> #FileA
> import Foundation
> 
> Struct A {
> private var x:Int
> hidden var y:Int  //This is just like fileprivate, but can 
> also be shared with other files
> }
> 
> extension A {
> //y can be accessed here because they are in the same file
> }
> 
> 
> #FileB
> import Foundation
> import hidden A  //This allows the entire file to see A’s hidden 
> variables
> 
> extension A {
> //y can be accessed here because of the ‘import hidden’ 
> declaration
> }
> 
> 
> #FileC
> import Foundation
> 
> extension A {
> //y can NOT be seen or accessed here because it is hidden
> }
> 
> 
> I think this is a fairly elegant solution to our protected dilemma, which 
> 

Re: [swift-evolution] [Pitch] Adding in Optional Argument labels for completion handlers

[Grant Kemp via swift-evolution]

Thanks for the lovely welcome, and for sharing your perspectives.

It sounds like I am not alone on this.
In terms of the timings, given the vast number of:
- 3rd party libraries
- Open source apps
- Enterprise projects
that leverage completion handlers, and are steadfastly stripping their
argument labels away and wondering why this useful feature is gone.  To
protect Swift's great reputation for swiftness, readibliity and clarity, I
would quite like to have those "stripping" out efforts avoided before
everyone has fully jumped to Swift 3.

I would quite like a  fix included in the 3.x branch if its in any way
possible ( to agree with Xiaodi Wu) otherwise I will just have to bite the
bullet and know that there is sunshine on the horizon in the form of Swift
4.

Cheers

On Mon, 17 Oct 2016 at 00:23 Xiaodi Wu  wrote:

> Honestly, given that the detailed implementation is core team-approved, I
> wonder if it ought to be just one of those rare pre-accepted proposals
> instead. It may not be ABI impacting, but as a bugfix for a Swift 3
> proposal there's a good argument it should go out in 3.x. My two cents
> anyway.
>
>
> On Mon, Oct 17, 2016 at 07:16 Austin Zheng  wrote:
>
> It seems like that link should be added to the 'frequently proposed
> changes' page on the repo. I'll prepare a PR.
>
> Austin
>
>
> On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Welcome to the list! It seems the community and core team are in agreement
> about your point. As mentioned previously, the core team has laid out a
> two-step roadmap to restoring argument labels:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html
>
> Hope that helps!
> On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all
> A South African in London here and I have decided to make the jump to
> trying to help Swift develop.
>
> I was an android and web developer and swift converted me to iOS
> programming which has become something that I love. I have built several
> apps on iOS and on macOS using it and thoroughly enjoyed it.
>
> One think has made me fall a little out of love with swift 3 was
> the removal of completion handler argument labels which has created:
> 1. Less maintainable code for teams
> 2. Less readable and thus more error prone code
> 3. Slower code to write as now I have to regularly scroll to the top of
> the method to find out what the parameters should be .
> 4. Seems to be at odds with other parts of the api which favours labels.
>
> I have found quite a lot of support from others via my stack overflow
> question here:
>
> http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build
>
> Here is my suggestion:
> Currently the Swift 3 version does not allow arguments in the
> completionhandler method, which is confusing and not very readable.
>
> func myMethod(_ completionhandler:(_ downloadedValue:String,_
> isActive:Bool, _ error:NSError)-> Void) {
> //< >>
>
> completionhandler(myString, true, myError)
>
> }
> // INSTEAD: ideally the argument labels should be added optionally to
> be called in the completion method such as below and using a Tuple-like
> syntax to indicate that the method should have the labels
>
> func myMethod(_ completionhandler:( downloadedValue:String, isActive:
> Bool,  error:NSError)-> Void) {
>
> //< >>
>
> completionhandler(dowloadedValue:myString, isActive:true,
> error:myError)
>
> }
>
>
> Thanks for the help ( and any feedback on my idea above )
>
> Thanks for the epic work you are doing !
> --
> Sent from my mobile
> ___
> 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
>
>
> --
Sent from my mobile
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Srstka via swift-evolution]

> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
>> Benjamin:
>> 
>> Implementation wise, weak does *not* currently have the effect of storing 
>> associated values. It does however mean that any object with weak references 
>> stays allocated after being deinited, until all the weak references are 
>> evaluated and zeroed (they are not zeroed when the object deinits, zeroing 
>> is done lazily. See 
>> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
>>  
>> 
>>  for a detailed discussion).
>> 
>> However, this seems likely to change at some point when Greg's changes are 
>> merged. Weakly referenced objects would cause a side-table to be allocated, 
>> with the benefits that the object could be deallocated immediately after 
>> deinit, and only the side-table would hang around (to service attempts to 
>> access weak references, which would still be lazily zeroed). The small 
>> disadvantage of this (which only applies to instances that actually have had 
>> weak references) is that an extra pointer dereference is needed for retain, 
>> release, and weak reference access (and some other things). But a big 
>> advantage is that the side-allocation could be used for other things too, 
>> like stored properties.
> 
> Thanks for the reference to the article.  I always meant to take the time to 
> do that bit spelunking, never actually had the time, and the non-code 
> documentation I found claimed it was out of date so I didn't bother reading 
> it.  Of all the possible implementations I conjectured after hearing about 
> ARC when it was announced for Obj-C, this was not one of them.  And frankly, 
> reading it makes me want to quit working as a software developer and take up 
> writing psychological thrillers as my job.  :(

The implementation in Objective-C ARC was not the same as Swift's, IIRC. I 
believe that it zeroed the references out immediately at the time the object 
ran out of references, rather than doing it lazily the next time something 
tried to access the reference. I could be wrong, though.

Charles

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

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Benjamin Spratling via swift-evolution]

>> Benjamin:
>> 
>> Implementation wise, weak does *not* currently have the effect of storing 
>> associated values. It does however mean that any object with weak references 
>> stays allocated after being deinited, until all the weak references are 
>> evaluated and zeroed (they are not zeroed when the object deinits, zeroing 
>> is done lazily. See 
>> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
>>  for a detailed discussion).
>> 
>> However, this seems likely to change at some point when Greg's changes are 
>> merged. Weakly referenced objects would cause a side-table to be allocated, 
>> with the benefits that the object could be deallocated immediately after 
>> deinit, and only the side-table would hang around (to service attempts to 
>> access weak references, which would still be lazily zeroed). The small 
>> disadvantage of this (which only applies to instances that actually have had 
>> weak references) is that an extra pointer dereference is needed for retain, 
>> release, and weak reference access (and some other things). But a big 
>> advantage is that the side-allocation could be used for other things too, 
>> like stored properties.

Thanks for the reference to the article.  I always meant to take the time to do 
that bit spelunking, never actually had the time, and the non-code 
documentation I found claimed it was out of date so I didn't bother reading it. 
 Of all the possible implementations I conjectured after hearing about ARC when 
it was announced for Obj-C, this was not one of them.  And frankly, reading it 
makes me want to quit working as a software developer and take up writing 
psychological thrillers as my job.  :(___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

T.J.: This would not replace the need for stored properties in extensions.
For example: Imagine adding a property to UIView in an extension, then
recursively traversing a view hierarchy and accessing the property. This
thought experiment should quickly show you why wrapping and adding
properties (or even subclassing and adding properties) simply won't work,
even if an easy forwarding mechanism were in place. You do not have control
of the creation of all those objects, so you can't make them your type, and
even if you could, you would have to provide a wrapper class for every
UIView subclass, and then what if another module also wants to do the same?

However, note that it would be possible to only add the extra storage to
instances where some additional properties are actually accessed/in-use.
The pointer for the stored property data in the side-table would simply be
nil if it has never been used.

On Sun, 16 Oct 2016 at 23:31 T.J. Usiyan  wrote:

> How much would convenient method forwarding when wrapping change how
> desirable this feature is? I am hesitant to add storage to already
> allocated instances if we can avoid it.
>
> On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Greg:
>
> I've CCed you in case you want to respond to my comments below about
> potentially optimising "extensionIvar" access without using a dictionary.
> See my response to Haravikk below.
>
> Benjamin:
>
> Implementation wise, weak does *not* currently have the effect of storing
> associated values. It does however mean that any object with weak
> references stays allocated after being deinited, until all the weak
> references are evaluated and zeroed (they are not zeroed when the object
> deinits, zeroing is done lazily. See
> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
> for a detailed discussion).
>
> However, this seems likely to change at some point when Greg's changes are
> merged. Weakly referenced objects would cause a side-table to be allocated,
> with the benefits that the object could be deallocated immediately after
> deinit, and only the side-table would hang around (to service attempts to
> access weak references, which would still be lazily zeroed). The small
> disadvantage of this (which only applies to instances that actually have
> had weak references) is that an extra pointer dereference is needed for
> retain, release, and weak reference access (and some other things). But a
> big advantage is that the side-allocation could be used for other things
> too, like stored properties.
>
> Haravikk:
>
> It can be done efficiently using Greg's proposed changes. The current
> implementation on his branch (
> https://github.com/gparker42/swift/tree/new-refcount-representation) does
> not have any extra space for stored properties, but he has discussed
> "extensionIvars" before on swift-dev, and proposed that the side-table
> structure contains a pointer to a dictionary for these. However, I think
> with some dynamic loader magic this could be implemented as a dynamic
> structure instead of a dictionary. Each time a module is loaded, the side
> allocation for stored properties could be extended and the offsets to the
> newly extended properties could be fixed-up based on the current size.
> Existing instances could be handled by using the structure size as a
> version number (stored at the beginning of this area), it would check if
> the instance is at the current version and migrate/update the structure as
> needed (realloc it and init the extended area to zero, updating the
> size/version field). These checks would be less overhead than a
> getter/setter function call, so using dot notation to access the properties
> would not be deceiving programmers about the cost.
>
> Anton:
>
> Why should it matter where data is stored? Can you expand on any reasons
> for wanting object data to be contiguous, or thinking that it shouldn't be
> allowed for Swift classes?
>
>
> ___
> 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] Adding in Optional Argument labels for completion handlers

[Xiaodi Wu via swift-evolution]

Honestly, given that the detailed implementation is core team-approved, I
wonder if it ought to be just one of those rare pre-accepted proposals
instead. It may not be ABI impacting, but as a bugfix for a Swift 3
proposal there's a good argument it should go out in 3.x. My two cents
anyway.


On Mon, Oct 17, 2016 at 07:16 Austin Zheng  wrote:

> It seems like that link should be added to the 'frequently proposed
> changes' page on the repo. I'll prepare a PR.
>
> Austin
>
>
> On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Welcome to the list! It seems the community and core team are in agreement
> about your point. As mentioned previously, the core team has laid out a
> two-step roadmap to restoring argument labels:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html
>
> Hope that helps!
> On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all
> A South African in London here and I have decided to make the jump to
> trying to help Swift develop.
>
> I was an android and web developer and swift converted me to iOS
> programming which has become something that I love. I have built several
> apps on iOS and on macOS using it and thoroughly enjoyed it.
>
> One think has made me fall a little out of love with swift 3 was
> the removal of completion handler argument labels which has created:
> 1. Less maintainable code for teams
> 2. Less readable and thus more error prone code
> 3. Slower code to write as now I have to regularly scroll to the top of
> the method to find out what the parameters should be .
> 4. Seems to be at odds with other parts of the api which favours labels.
>
> I have found quite a lot of support from others via my stack overflow
> question here:
>
> http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build
>
> Here is my suggestion:
> Currently the Swift 3 version does not allow arguments in the
> completionhandler method, which is confusing and not very readable.
>
> func myMethod(_ completionhandler:(_ downloadedValue:String,_
> isActive:Bool, _ error:NSError)-> Void) {
> //< >>
>
> completionhandler(myString, true, myError)
>
> }
> // INSTEAD: ideally the argument labels should be added optionally to
> be called in the completion method such as below and using a Tuple-like
> syntax to indicate that the method should have the labels
>
> func myMethod(_ completionhandler:( downloadedValue:String, isActive:
> Bool,  error:NSError)-> Void) {
>
> //< >>
>
> completionhandler(dowloadedValue:myString, isActive:true,
> error:myError)
>
> }
>
>
> Thanks for the help ( and any feedback on my idea above )
>
> Thanks for the epic work you are doing !
> --
> Sent from my mobile
> ___
> 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] Adding in Optional Argument labels for completion handlers

[Austin Zheng via swift-evolution]

It seems like that link should be added to the 'frequently proposed changes' 
page on the repo. I'll prepare a PR.

Austin

> On Oct 16, 2016, at 4:09 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Welcome to the list! It seems the community and core team are in agreement 
> about your point. As mentioned previously, the core team has laid out a 
> two-step roadmap to restoring argument labels:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html
>  
> 
> 
> Hope that helps!
> On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution 
> > wrote:
> Hi all
> A South African in London here and I have decided to make the jump to trying 
> to help Swift develop. 
> 
> I was an android and web developer and swift converted me to iOS programming 
> which has become something that I love. I have built several apps on iOS and 
> on macOS using it and thoroughly enjoyed it. 
> 
> One think has made me fall a little out of love with swift 3 was the removal 
> of completion handler argument labels which has created:
> 1. Less maintainable code for teams 
> 2. Less readable  and thus more error prone code 
> 3. Slower code to write as now I have to regularly scroll to the top of the 
> method to find out what the parameters should be . 
> 4. Seems to be at odds with other parts of the api which favours labels. 
> 
> I have found quite a lot of support from others via my stack overflow 
> question here: 
> http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build
>  
> 
> 
> Here is my suggestion: 
> Currently the Swift 3 version does not allow arguments in the 
> completionhandler method, which is confusing and not very readable.
> func myMethod(_ completionhandler:(_ downloadedValue:String,_ 
> isActive:Bool, _ error:NSError)-> Void) {
> //<>
> 
> completionhandler(myString, true, myError)
> 
> }
> // INSTEAD: ideally the argument labels should be added optionally to be 
> called in the completion method such as below and using a Tuple-like syntax 
> to indicate that the method should have the labels
> 
> func myMethod(_ completionhandler:( downloadedValue:String, 
> isActive:Bool,  error:NSError)-> Void) {
> 
> //<>
> 
> completionhandler(dowloadedValue:myString, isActive:true, 
> error:myError)
> 
> }
> 
> 
> 
> Thanks for the help ( and any feedback on my idea above ) 
> 
> Thanks for the epic work you are doing ! 
> -- 
> Sent from my mobile
> ___
> 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] Adding in Optional Argument labels for completion handlers

[Hooman Mehr via swift-evolution]

This is an unfortunate side effect of another important and necessary change: 
Making argument labels part of functions name. This means that closures (which 
are anonymous functions and lack a function name) now don’t have any place to 
keep the argument labels. 

Using a labeled tuple as a single argument block could act as a workaround for 
now, but:

I think we really need to find the correct way to add back argument labels for 
closures. I strongly suspect such a change will be ABI breaking.

People (including myself) are getting some experience with actual implications 
and feel of lack of argument labels for anonymous functions. As far as I can 
tell, nobody likes this and it feels so very un-Swifty and a big step backwards.

Lets find a way to add back argument labels to closures for Swift 4.

> On Oct 16, 2016, at 3:33 PM, Grant Kemp via swift-evolution 
>  wrote:
> 
> Hi all
> A South African in London here and I have decided to make the jump to trying 
> to help Swift develop. 
> 
> I was an android and web developer and swift converted me to iOS programming 
> which has become something that I love. I have built several apps on iOS and 
> on macOS using it and thoroughly enjoyed it. 
> 
> One think has made me fall a little out of love with swift 3 was the removal 
> of completion handler argument labels which has created:
> 1. Less maintainable code for teams 
> 2. Less readable  and thus more error prone code 
> 3. Slower code to write as now I have to regularly scroll to the top of the 
> method to find out what the parameters should be . 
> 4. Seems to be at odds with other parts of the api which favours labels. 
> 
> I have found quite a lot of support from others via my stack overflow 
> question here: 
> http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build
>  
> 
> 
> Here is my suggestion: 
> Currently the Swift 3 version does not allow arguments in the 
> completionhandler method, which is confusing and not very readable.
> func myMethod(_ completionhandler:(_ downloadedValue:String,_ 
> isActive:Bool, _ error:NSError)-> Void) {
> //<>
> 
> completionhandler(myString, true, myError)
> 
> }
> // INSTEAD: ideally the argument labels should be added optionally to be 
> called in the completion method such as below and using a Tuple-like syntax 
> to indicate that the method should have the labels
> 
> func myMethod(_ completionhandler:( downloadedValue:String, 
> isActive:Bool,  error:NSError)-> Void) {
> 
> //<>
> 
> completionhandler(dowloadedValue:myString, isActive:true, 
> error:myError)
> 
> }
> 
> 
> 
> Thanks for the help ( and any feedback on my idea above ) 
> 
> Thanks for the epic work you are doing ! 
> -- 
> Sent from my mobile
> ___
> 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] Adding in Optional Argument labels for completion handlers

[Xiaodi Wu via swift-evolution]

Welcome to the list! It seems the community and core team are in agreement
about your point. As mentioned previously, the core team has laid out a
two-step roadmap to restoring argument labels:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html

Hope that helps!
On Mon, Oct 17, 2016 at 06:35 Grant Kemp via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all
> A South African in London here and I have decided to make the jump to
> trying to help Swift develop.
>
> I was an android and web developer and swift converted me to iOS
> programming which has become something that I love. I have built several
> apps on iOS and on macOS using it and thoroughly enjoyed it.
>
> One think has made me fall a little out of love with swift 3 was
> the removal of completion handler argument labels which has created:
> 1. Less maintainable code for teams
> 2. Less readable and thus more error prone code
> 3. Slower code to write as now I have to regularly scroll to the top of
> the method to find out what the parameters should be .
> 4. Seems to be at odds with other parts of the api which favours labels.
>
> I have found quite a lot of support from others via my stack overflow
> question here:
>
> http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build
>
> Here is my suggestion:
> Currently the Swift 3 version does not allow arguments in the
> completionhandler method, which is confusing and not very readable.
>
> func myMethod(_ completionhandler:(_ downloadedValue:String,_
> isActive:Bool, _ error:NSError)-> Void) {
> //< >>
>
> completionhandler(myString, true, myError)
>
> }
> // INSTEAD: ideally the argument labels should be added optionally to
> be called in the completion method such as below and using a Tuple-like
> syntax to indicate that the method should have the labels
>
> func myMethod(_ completionhandler:( downloadedValue:String, isActive:
> Bool,  error:NSError)-> Void) {
>
> //< >>
>
> completionhandler(dowloadedValue:myString, isActive:true,
> error:myError)
>
> }
>
>
> Thanks for the help ( and any feedback on my idea above )
>
> Thanks for the epic work you are doing !
> --
> Sent from my mobile
> ___
> 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] [Pitch] Adding in Optional Argument labels for completion handlers

[Grant Kemp via swift-evolution]

Hi all
A South African in London here and I have decided to make the jump to
trying to help Swift develop.

I was an android and web developer and swift converted me to iOS
programming which has become something that I love. I have built several
apps on iOS and on macOS using it and thoroughly enjoyed it.

One think has made me fall a little out of love with swift 3 was
the removal of completion handler argument labels which has created:
1. Less maintainable code for teams
2. Less readable and thus more error prone code
3. Slower code to write as now I have to regularly scroll to the top of the
method to find out what the parameters should be .
4. Seems to be at odds with other parts of the api which favours labels.

I have found quite a lot of support from others via my stack overflow
question here:
http://stackoverflow.com/questions/39613272/xcode-8-function-types-cannot-have-argument-label-breaking-my-build

Here is my suggestion:
Currently the Swift 3 version does not allow arguments in the
completionhandler method, which is confusing and not very readable.

func myMethod(_ completionhandler:(_ downloadedValue:String,_ isActive:
Bool, _ error:NSError)-> Void) {
//<>

completionhandler(myString, true, myError)

}
// INSTEAD: ideally the argument labels should be added optionally to
be called in the completion method such as below and using a Tuple-like
syntax to indicate that the method should have the labels

func myMethod(_ completionhandler:( downloadedValue:String, isActive:
Bool,  error:NSError)-> Void) {

//<>

completionhandler(dowloadedValue:myString, isActive:true,
error:myError)

}


Thanks for the help ( and any feedback on my idea above )

Thanks for the epic work you are doing !
-- 
Sent from my mobile
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[T.J. Usiyan via swift-evolution]

How much would convenient method forwarding when wrapping change how
desirable this feature is? I am hesitant to add storage to already
allocated instances if we can avoid it.

On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

> Greg:
>
> I've CCed you in case you want to respond to my comments below about
> potentially optimising "extensionIvar" access without using a dictionary.
> See my response to Haravikk below.
>
> Benjamin:
>
> Implementation wise, weak does *not* currently have the effect of storing
> associated values. It does however mean that any object with weak
> references stays allocated after being deinited, until all the weak
> references are evaluated and zeroed (they are not zeroed when the object
> deinits, zeroing is done lazily. See https://www.mikeash.com/
> pyblog/friday-qa-2015-12-11-swift-weak-references.html for a detailed
> discussion).
>
> However, this seems likely to change at some point when Greg's changes are
> merged. Weakly referenced objects would cause a side-table to be allocated,
> with the benefits that the object could be deallocated immediately after
> deinit, and only the side-table would hang around (to service attempts to
> access weak references, which would still be lazily zeroed). The small
> disadvantage of this (which only applies to instances that actually have
> had weak references) is that an extra pointer dereference is needed for
> retain, release, and weak reference access (and some other things). But a
> big advantage is that the side-allocation could be used for other things
> too, like stored properties.
>
> Haravikk:
>
> It can be done efficiently using Greg's proposed changes. The current
> implementation on his branch (https://github.com/gparker42/
> swift/tree/new-refcount-representation) does not have any extra space for
> stored properties, but he has discussed "extensionIvars" before on
> swift-dev, and proposed that the side-table structure contains a pointer to
> a dictionary for these. However, I think with some dynamic loader magic
> this could be implemented as a dynamic structure instead of a dictionary.
> Each time a module is loaded, the side allocation for stored properties
> could be extended and the offsets to the newly extended properties could be
> fixed-up based on the current size. Existing instances could be handled by
> using the structure size as a version number (stored at the beginning of
> this area), it would check if the instance is at the current version and
> migrate/update the structure as needed (realloc it and init the extended
> area to zero, updating the size/version field). These checks would be less
> overhead than a getter/setter function call, so using dot notation to
> access the properties would not be deceiving programmers about the cost.
>
> Anton:
>
> Why should it matter where data is stored? Can you expand on any reasons
> for wanting object data to be contiguous, or thinking that it shouldn't be
> allowed for Swift classes?
>
>
> ___
> 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] Replace Fileprivate with Hidden + Import Hidden

[T.J. Usiyan via swift-evolution]

I don't like this at all and it comes down to  "what is hidden can also be
unhidden". This, to me, feels like it would create more confusion than it
would address. Why not just use `internal` for `hidden` items?  If we're ok
with modifying import statements, why not simply have a command that
imports `fileprivate` stuff? (not advocating for this).

I think that submodules would have really helped with this issue and it is
unfortunate that we couldn't get them in for swift 3.

On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I keep wanting a “protected” access level, but I must also admit that
> there was something really elegant about Swift 2’s access scheme (and I
> think most of us feel like the word ‘fileprivate’ feels out of place).  I
> was thinking about how to mesh those two ideas, and I think I may have come
> up with a solution.
>
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.
> Hidden would work exactly the same way as fileprivate does now, but adds
> the connotation that what is hidden can also be unhidden.  By adding
> ‘import hidden TypeName’ to another file, that file also gains access to
> all of the hidden items of that type (kind of like if it was in the same
> file).
>
> #FileA
> import Foundation
>
> Struct A {
> private var x:Int
> hidden var y:Int  //This is just like fileprivate, but can
> also be shared with other files
> }
>
> extension A {
> //y can be accessed here because they are in the same file
> }
>
>
> #FileB
> import Foundation
> import hidden A  //This allows the entire file to see A’s hidden
> variables
>
> extension A {
> //y can be accessed here because of the ‘import hidden’
> declaration
> }
>
>
> #FileC
> import Foundation
>
> extension A {
> //y can NOT be seen or accessed here because it is hidden
> }
>
>
> I think this is a fairly elegant solution to our protected dilemma, which
> also feels in sync with Swift 2’s file-based scheme.  The key features:
> • Extensions no longer need to be piled in the same file if it is
> getting too long
> • Subclasses can be in their own file, but still have access to
> the necessary parts of their superclass
> • It communicates the author’s intent that the items are not meant
> to be visible to its users, but that it is expected to be used for
> extension/subclassing
> • It requires an explicit statement ‘import hidden’ to access the
> hidden variables. Safe by default, with override.
> • It is not bound by module boundaries  (i.e. you could use it for
> subclassing classes from an imported module)
> • Roughly the same length as ‘private’ and ‘public’ so various
> declarations packed together are much easier to read (fileprivate breaks
> reading rhythm)
>
> Worth a formal proposal?
>
> Thanks,
> Jon
>
>
>
> ___
> 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] stored properties in extensions (was: associated objects)

[Jay Abbott via swift-evolution]

Greg:

I've CCed you in case you want to respond to my comments below about
potentially optimising "extensionIvar" access without using a dictionary.
See my response to Haravikk below.

Benjamin:

Implementation wise, weak does *not* currently have the effect of storing
associated values. It does however mean that any object with weak
references stays allocated after being deinited, until all the weak
references are evaluated and zeroed (they are not zeroed when the object
deinits, zeroing is done lazily. See
https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
for a detailed discussion).

However, this seems likely to change at some point when Greg's changes are
merged. Weakly referenced objects would cause a side-table to be allocated,
with the benefits that the object could be deallocated immediately after
deinit, and only the side-table would hang around (to service attempts to
access weak references, which would still be lazily zeroed). The small
disadvantage of this (which only applies to instances that actually have
had weak references) is that an extra pointer dereference is needed for
retain, release, and weak reference access (and some other things). But a
big advantage is that the side-allocation could be used for other things
too, like stored properties.

Haravikk:

It can be done efficiently using Greg's proposed changes. The current
implementation on his branch (
https://github.com/gparker42/swift/tree/new-refcount-representation) does
not have any extra space for stored properties, but he has discussed
"extensionIvars" before on swift-dev, and proposed that the side-table
structure contains a pointer to a dictionary for these. However, I think
with some dynamic loader magic this could be implemented as a dynamic
structure instead of a dictionary. Each time a module is loaded, the side
allocation for stored properties could be extended and the offsets to the
newly extended properties could be fixed-up based on the current size.
Existing instances could be handled by using the structure size as a
version number (stored at the beginning of this area), it would check if
the instance is at the current version and migrate/update the structure as
needed (realloc it and init the extended area to zero, updating the
size/version field). These checks would be less overhead than a
getter/setter function call, so using dot notation to access the properties
would not be deceiving programmers about the cost.

Anton:

Why should it matter where data is stored? Can you expand on any reasons
for wanting object data to be contiguous, or thinking that it shouldn't be
allowed for Swift classes?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] API Guidelines

[Dave Abrahams via swift-evolution]

on Fri Oct 14 2016, Adrian Zubarev  wrote:

> I’m still not convinced in some cases.
>
> Take a look at UIViews and its method addSubview.
>
> open func addSubview(_ view: UIView)
> Personally I’d change or write this function like so:
>
> open func add(subview: UIView)
> This reduces unnecessary noise _ view for both the implementation and usage.

No, the usage is either v1.addSubview(v2) or v1.add(subview: v2) Neither
usage introduces an underscore.  To a first approximation, how the
implementation looks is irrelevant.  APIs are used many more times than
they are written or looked up.

The word "subview" is part of the base name for at least two reasons:

1. The primary reason is that the base name should capture the method's
   core semantics, and adding a subview is semantically completely
   different from, say, adding a gesture recognizer.  They become parts
   of different logical collections on the view and come with utterly
   different side-effects.

2. It's important to have consistent and simple naming rules that work
   well for most APIs, and any rule we could think of that would lead us
   to breaking "add" from "subview" would either

   a) cause many APIs to become inarguably worse or
   b) neccessitate complicating the naming rules to avoid damaging those
  other APIs.

> // Implementation
> open func add(subview: UIView) {
> // `subview` is descriptive and just fine here
> }
>
> // Usage
>
> self.view.add(subview: someOtherView)
>
> -- 
> Adrian Zubarev
> Sent with Airmail
>
> Am 14. Oktober 2016 um 16:42:06, Zach Waldowski via swift-evolution
> (swift-evolution@swift.org) schrieb:
>
> The base name of the function describes its core purpose.
>
> There is no ambiguity instructing an Array to "append" something, but
> there is context needed: "what are we appending? The contents of the
> newElements parameter." But there is ambiguity asking URL to "give me a
> new URL by appending". Appending what? Similarly, telling a collection
> to "replace". Replace what?
>
> A rule of thumb my team has applied is to put the parameter parens where
> you would have put `with` in ObjC. This is instructive for your
> questions as well. "URLByAppendingWithPathComponent" and
> "replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
> does.
>
> Cheers!
>   Zachary Waldowski
>   z...@waldowski.me
>
> On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
> wrote:
>> Hi there,
>>  
>> I am really grateful for the API guidelines that were created as part of
>> Swift 3, however, I'm having trouble with distinguishing which part of
>> the method name should be already an argument. To illustrate this, here
>> are two examples:
>>  
>> // On Array
>> public mutating func append(contentsOf newElements: S)
>>  
>> // On Foundation.URL
>> public func appendingPathComponent(_ pathComponent: String) -> URL
>>  
>>  
>> Is there a particular reason why it's not
>>  
>> public func appending(pathComponent: String) -> URL
>>  
>> ?
>>  
>> In my opinion the entire stdlib and Foundation is full of such
>> discrepancies which make it hard to decide when you name your own methods
>> since there are preceding cases in the language itself (or Foundation)
>> that go both ways.
>>  
>> The same goes for why don't the replace methods (this is on String)
>> follow the same - when there is append(contentsOf:):
>>  
>> public mutating func replaceSubrange(_ bounds: ClosedRange,
>> with newElements: String)
>>  
>> instead of
>>  
>> public mutating func replace(subrange bounds: ClosedRange,
>> with newElements: String)
>>  
>>  
>>  
>> I know there was an extensive discussion about this here when the stdlib
>> names were discussed. And given that these would be breaking changes, I
>> don't necessarily want to start a lengthy discussion about renaming those
>> again - I'm just wondering what are the reasons behind this and what
>> should be the correct naming conventions.
>>  
>> Thanks!
>>  
>> Charlie
>> ___
>> 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
>

-- 
-Dave

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

Re: [swift-evolution] [Discussion] API Guidelines

[Dave Abrahams via swift-evolution]

on Fri Oct 14 2016, Zach Waldowski  wrote:

> The base name of the function describes its core purpose.
>
> There is no ambiguity instructing an Array to "append" something, but
> there is context needed: "what are we appending? The contents of the
> newElements parameter." 

That's because there's a distinction between appending the newElements
paramter (as a single new element on an array of Any) and appending its
elements.

> But there is ambiguity asking URL to "give me a new URL by
> appending". Appending what?

Actually, no, you are passing an argument.  That's what's being
appended.  If there's only one reasonable way to append a String to a
URL, no noun should be needed.  If there's some ambiguity as to the
semantics, that might justify the "pathComponent:" label.

> Similarly, telling a collection to "replace". Replace what?
>
> A rule of thumb my team has applied is to put the parameter parens where
> you would have put `with` in ObjC. This is instructive for your
> questions as well. "URLByAppendingWithPathComponent" and
> "replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
> does.
>
> Cheers!
>   Zachary Waldowski
>   z...@waldowski.me
>
> On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
> wrote:
>> Hi there,
>> 
>> I am really grateful for the API guidelines that were created as part of
>> Swift 3, however, I'm having trouble with distinguishing which part of
>> the method name should be already an argument. To illustrate this, here
>> are two examples:
>> 
>> // On Array
>> public mutating func append(contentsOf newElements: S)
>> 
>> // On Foundation.URL
>> public func appendingPathComponent(_ pathComponent: String) -> URL
>> 
>> 
>> Is there a particular reason why it's not
>> 
>> public func appending(pathComponent: String) -> URL
>> 
>> ?
>> 
>> In my opinion the entire stdlib and Foundation is full of such
>> discrepancies which make it hard to decide when you name your own methods
>> since there are preceding cases in the language itself (or Foundation)
>> that go both ways.
>> 
>> The same goes for why don't the replace methods (this is on String)
>> follow the same - when there is append(contentsOf:):
>> 
>> public mutating func replaceSubrange(_ bounds: ClosedRange,
>> with newElements: String)
>> 
>> instead of
>> 
>> public mutating func replace(subrange bounds: ClosedRange,
>> with newElements: String)
>> 
>> 
>> 
>> I know there was an extensive discussion about this here when the stdlib
>> names were discussed. And given that these would be breaking changes, I
>> don't necessarily want to start a lengthy discussion about renaming those
>> again - I'm just wondering what are the reasons behind this and what
>> should be the correct naming conventions.
>> 
>> Thanks!
>> 
>> Charlie
>> ___
>> 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

-- 
-Dave

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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jay Abbott via swift-evolution]

> * What is your evaluation of the proposal?

I am against it.

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

No - if this change were made it would be a regression. The rationale for
removing it in the first place was and remains valid.

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

No, it goes in the opposite direction. $ is not valid as the first
character of a user-defined identifier and therefore should not be a valid
identifier by itself.

Side-note: Personally I think $ as the first character of an identifier
should be reserved for shorthand ways to do other things, in line with how
it is currently used in Swift.
If used consistently, programmers will know they are seeing a language
shortcut. Allowing $ as an identifier would break some of the natural
intuition a programmer is able to use when learning and reading Swift code.

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

The proposal seems purely for the benefit of the Dollar library, which
could work just as well with any other identifier. Code using the dollar
library is reminiscent of some other languages and programming styles. This
isn't really a comment about the proposal itself, more the motivation
behind it.

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

I read the proposal and was perplexed by it, so I looked into the Dollar
library to try and understand the motivation behind the proposal. It is a
clever library with some nice features and tricks, but in many ways it
seems to be designed to enable programmers to write non-Swifty code in
Swift. I can understand the frustration of the author and users of the
library, but its functionality could be provided in a Swifty way using
extensions and generics, and I think if those users embraced this they
would ultimately appreciate the change. If not then they might as well
stick to another language.


On Sun, 16 Oct 2016 at 17:31 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>
>
> * What is your evaluation of the proposal?
>
>
> -1.
>
> The proposal does not actually provide motivation for keeping $ beyond
> "the Dollar library already uses it".
>
> A more Swifty way for a library to introduce these operations would be
> with extensions. Here are some suggestions, based off the first several
> operations described in the library's readme:
>
> $.at → convenience subscript(Index...) for Collection
> $.chunk → convenience function for Sequence
> $.compact → flatMap{$0}
> $.contains → already exists as Sequence.contains
> $.cycle → convenience function for Collection
> $.difference → convenience function on Collection, or just use Set
> operations, or filter
> $.each → exists as Sequence.forEach
> $.every → extension on Sequence
> $.factorial → convenience method or postfix operator for Integer
> $.fetch → convenience function on Collection
> and so on.
>
> It looks like the author's Cent  library
> is already taking this approach.
>
>
>
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
>
> Yes, but the change has already been made: removing $ as a valid
> identifier ;-)
>
>
>
> * Does this proposal fit well with the feel and direction of Swift?
>
>
> Not really. If anything, IMO, the dollar sign feels more like an operator
> character. (However, it's probably here to stay in identifiers because of
> closure parameters and LLDB variables.)
>
>
>
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
>
> The Dollar library resembles the style of JavaScript libraries such as
> jQuery or Underscore, but that isn't a positive thing in my mind — as
> mentioned above, the Swift way of doing things is different.
>
>
>
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
>
> Thorough reading of the proposal; brief glance at the library's readme on
> GitHub.  Lots of time thinking about operator & identifier characters for a
> forthcoming proposal.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Georgios Moschovitis via swift-evolution]

> In Swift, we have pretty consistently tried to choose the "right" answer to 
> make the resulting language consistent and beautiful.
> I'm perfectly happy to have a discussion about the naming, but I would like 
> it to be driven by what we believe the "right" answer is, not simply by 
> deference to existing solutions.

+100

Moreover, after your explanation, `lock` feels wrong to me too. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jacob Bandes-Storch via swift-evolution]

Proposal link:

https://github.com/apple/swift-evolution/blob/master/propo
sals/0144-allow-single-dollar-sign-as-valid-identifier.md


> * What is your evaluation of the proposal?
>

-1.

The proposal does not actually provide motivation for keeping $ beyond "the
Dollar library already uses it".

A more Swifty way for a library to introduce these operations would be with
extensions. Here are some suggestions, based off the first several
operations described in the library's readme:

$.at → convenience subscript(Index...) for Collection
$.chunk → convenience function for Sequence
$.compact → flatMap{$0}
$.contains → already exists as Sequence.contains
$.cycle → convenience function for Collection
$.difference → convenience function on Collection, or just use Set
operations, or filter
$.each → exists as Sequence.forEach
$.every → extension on Sequence
$.factorial → convenience method or postfix operator for Integer
$.fetch → convenience function on Collection
and so on.

It looks like the author's Cent  library is
already taking this approach.



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

Yes, but the change has already been made: removing $ as a valid identifier
;-)



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

Not really. If anything, IMO, the dollar sign feels more like an operator
character. (However, it's probably here to stay in identifiers because of
closure parameters and LLDB variables.)



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

The Dollar library resembles the style of JavaScript libraries such as
jQuery or Underscore, but that isn't a positive thing in my mind — as
mentioned above, the Swift way of doing things is different.



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

Thorough reading of the proposal; brief glance at the library's readme on
GitHub.  Lots of time thinking about operator & identifier characters for a
forthcoming proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Fons Rademakers via swift-evolution]

> 
>   * What is your evaluation of the proposal?

-1

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

no

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

no

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

perl feeling, don’t like it as part of a modern clear and concise language.

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

quick reading.


> More information about the Swift evolution process is available at
> 


--
Dr. Fons Rademakers  CERN - European Organization for Nuclear Research
Chief Research Officer   1211 Geneve 23, Switzerland
CERN openlab Tel: +41227679248Mobile: +41754113742
--

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

Re: [swift-evolution] Tuples as RawRepresentable

[Xiaodi Wu via swift-evolution]

It may be farther reaching, but it's quite salient. Completing genetics is
a Swift 4 focus, and protocol conformance and extensions of structural
types may well have ABI implications, which would make it a phase 1
priority.

Recall that equality for tuples of Equatables is only defined up to an
arity of 6, and that it was implemented in that way as a stopgap. With a
plausible definitive solution in scope for Swift 4, it seems less than
ideal to propose entrenching the stopgap measure by making it even more
elaborate.

On Sun, Oct 16, 2016 at 19:47 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 16 Oct 2016, at 11:55, Karl  wrote:
>
>
> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
> Tuples cannot conform to protocols, so despite the existence of an “==”
> operator for certain tuples, no tuple conforms to Equatable.
>
> This is problematic, because it means that a function which takes a
> generic Equatable parameter cannot be called with a tuple argument, even
> though an applicable “==” operator exists.
>
> (Ditto for “Comparable”, *mutatis mutandis*.)
>
> Nevin
>
>
> Yeah, since the operators are implemented though perhaps some kind of
> magic can be used? It seems strange that the following is valid:
>
> struct Foo : Equatable { let value:(Int, Int) }
> func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value }
>
> Yet tuples can't just be Equatable etc. But I'm wondering whether that
> falls into separate issue territory, such that it should be done first as
> its own proposal?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Tuples are non-nominal (named) types, and that’s why they can’t conform to
> protocols. There is something in the generics manifesto about possibly
> allowing them to do that in the future, though:
>
>
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>
> Extensions of structural types
>
> Currently, only nominal types (classes, structs, enums, protocols) can be
> extended. One could imagine extending structural types—particularly tuple
> types—to allow them to, e.g., conform to protocols. For example, pulling
> together variadic generics, parameterized extensions, and conditional
> conformances, one could express "a tuple type is Equatable if all of its
> element types are Equatable":
>
> extension<...Elements : Equatable> (Elements...) : Equatable {   // extending 
> the tuple type "(Elements...)" to be Equatable
> }
>
> - Karl
>
>
> Yeah, but that's much further reaching overall; I'm wondering whether it's
> okay to just call tuples of Equatable types Equatable for the purposes of
> getting them as enum raw values? I'll maybe put some discussion of timing
> and other issues into the proposal for this, to keep it open ended.
> ___
> 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] Tuples as RawRepresentable

[Haravikk via swift-evolution]

> On 16 Oct 2016, at 11:55, Karl  wrote:
> 
> 
>> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky 
>>> >> > wrote:
>>> 
>>> Tuples cannot conform to protocols, so despite the existence of an “==” 
>>> operator for certain tuples, no tuple conforms to Equatable.
>>> 
>>> This is problematic, because it means that a function which takes a generic 
>>> Equatable parameter cannot be called with a tuple argument, even though an 
>>> applicable “==” operator exists.
>>> 
>>> (Ditto for “Comparable”, mutatis mutandis.)
>>> 
>>> Nevin
>> 
>> Yeah, since the operators are implemented though perhaps some kind of magic 
>> can be used? It seems strange that the following is valid:
>> 
>>  struct Foo : Equatable { let value:(Int, Int) }
>>  func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value }
>> 
>> Yet tuples can't just be Equatable etc. But I'm wondering whether that falls 
>> into separate issue territory, such that it should be done first as its own 
>> proposal?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Tuples are non-nominal (named) types, and that’s why they can’t conform to 
> protocols. There is something in the generics manifesto about possibly 
> allowing them to do that in the future, though: 
> 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>  
> 
>> Extensions of structural types
>> 
>> Currently, only nominal types (classes, structs, enums, protocols) can be 
>> extended. One could imagine extending structural types—particularly tuple 
>> types—to allow them to, e.g., conform to protocols. For example, pulling 
>> together variadic generics, parameterized extensions, and conditional 
>> conformances, one could express "a tuple type is Equatable if all of its 
>> element types are Equatable":
>> 
>> extension<...Elements : Equatable> (Elements...) : Equatable {   // 
>> extending the tuple type "(Elements...)" to be Equatable
>> }
> 
> - Karl

Yeah, but that's much further reaching overall; I'm wondering whether it's okay 
to just call tuples of Equatable types Equatable for the purposes of getting 
them as enum raw values? I'll maybe put some discussion of timing and other 
issues into the proposal for this, to keep it open ended.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Karl via swift-evolution]

> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky 
>> > 
>> wrote:
>> 
>> Tuples cannot conform to protocols, so despite the existence of an “==” 
>> operator for certain tuples, no tuple conforms to Equatable.
>> 
>> This is problematic, because it means that a function which takes a generic 
>> Equatable parameter cannot be called with a tuple argument, even though an 
>> applicable “==” operator exists.
>> 
>> (Ditto for “Comparable”, mutatis mutandis.)
>> 
>> Nevin
> 
> Yeah, since the operators are implemented though perhaps some kind of magic 
> can be used? It seems strange that the following is valid:
> 
>   struct Foo : Equatable { let value:(Int, Int) }
>   func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value }
> 
> Yet tuples can't just be Equatable etc. But I'm wondering whether that falls 
> into separate issue territory, such that it should be done first as its own 
> proposal?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Tuples are non-nominal (named) types, and that’s why they can’t conform to 
protocols. There is something in the generics manifesto about possibly allowing 
them to do that in the future, though: 

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
 

> Extensions of structural types
> 
> Currently, only nominal types (classes, structs, enums, protocols) can be 
> extended. One could imagine extending structural types—particularly tuple 
> types—to allow them to, e.g., conform to protocols. For example, pulling 
> together variadic generics, parameterized extensions, and conditional 
> conformances, one could express "a tuple type is Equatable if all of its 
> element types are Equatable":
> 
> extension<...Elements : Equatable> (Elements...) : Equatable {   // extending 
> the tuple type "(Elements...)" to be Equatable
> }


- Karl

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

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Anton Zhilin via swift-evolution]

Purely additive feature, not for Swift 4 Phase 1.
And a -1 from me for reasons already mentioned.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Nicholas Maccharoli via swift-evolution]

+1

2016年10月16日日曜日、Rien via swift-evolutionさんは書きました:

> Specifically, I don’t care much. Say -0.1 :-)
>
> In general I am against “savings lines”.
> While very short modules (< 10) do indeed profit from having fewer lines,
> most modules don’t.
> Having a few more lines, even empty ones, can do a lot to improve code
> readability imo.
> Probably my Ada experience showing through….
>
> Rien.
>
> > On 16 Oct 2016, at 02:41, Charles Constant via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> > How would we all feel about allowing multiple modules with one import
> statement?
> >
> > Eg: the option to write
> >
> > import Cocoa, Foo, Bar.Baz
> >
> > in addition to just:
> >
> > import Cocoa
> > import Foo
> > import Bar.Baz
> >
> > When I'm writing smaller files that import a few modules, I'd  prefer to
> lump the imports together like this. Doesn't seem like a feature that would
> require much effort to implement either.
> >
> >
> > ___
> > 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] "import" declaration, support for comma-separated modules

[Rien via swift-evolution]

Specifically, I don’t care much. Say -0.1 :-)

In general I am against “savings lines”.
While very short modules (< 10) do indeed profit from having fewer lines, most 
modules don’t.
Having a few more lines, even empty ones, can do a lot to improve code 
readability imo.
Probably my Ada experience showing through….

Rien.

> On 16 Oct 2016, at 02:41, Charles Constant via swift-evolution 
>  wrote:
> 
> How would we all feel about allowing multiple modules with one import 
> statement? 
> 
> Eg: the option to write
> 
> import Cocoa, Foo, Bar.Baz  
> 
> in addition to just:
> 
> import Cocoa   
> import Foo 
> import Bar.Baz 
> 
> When I'm writing smaller files that import a few modules, I'd  prefer to lump 
> the imports together like this. Doesn't seem like a feature that would 
> require much effort to implement either.
> 
> 
> ___
> 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] "import" declaration, support for comma-separated modules

[Robert Widmann via swift-evolution]

-1.  This is not going to work particularly well with qualified import syntax 
(import {class|struct|enum|typealias} Module.Decl) and blurs disparate imports 
with each other.  I'd rather see grouping of related imports than save a few 
lines.

~Robert Widmann

2016/10/16 3:14、Richard Wei via swift-evolution  
のメッセージ:

> +1. Since we can do `let a, b, c, ...`, it makes sense for `import` to 
> support comma-separated lists.
> 
> -Richard
> 
>>> On Oct 15, 2016, at 20:24, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Oct 15, 2016, at 6:41 PM, Charles Constant via swift-evolution 
>>>  wrote:
>>> 
>>> How would we all feel about allowing multiple modules with one import 
>>> statement? 
>>> 
>>> Eg: the option to write
>>> 
>>> import Cocoa, Foo, Bar.Baz  
>>> 
>>> in addition to just:
>>> 
>>> import Cocoa   
>>> import Foo 
>>> import Bar.Baz 
>>> 
>>> When I'm writing smaller files that import a few modules, I'd  prefer to 
>>> lump the imports together like this. Doesn't seem like a feature that would 
>>> require much effort to implement either.
>> 
>> I'm fine with this. I'd also like `import as` to handle namespacing 
>> simplification and conflict resolution
>> 
>> `import Bar.Baz as Bif`
>> 
>> -- E
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Richard Wei via swift-evolution]

+1. Since we can do `let a, b, c, ...`, it makes sense for `import` to support 
comma-separated lists.

-Richard

> On Oct 15, 2016, at 20:24, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Oct 15, 2016, at 6:41 PM, Charles Constant via swift-evolution 
>> > wrote:
>> 
>> How would we all feel about allowing multiple modules with one import 
>> statement? 
>> 
>> Eg: the option to write
>> 
>> import Cocoa, Foo, Bar.Baz  
>> 
>> in addition to just:
>> 
>> import Cocoa   
>> import Foo 
>> import Bar.Baz 
>> 
>> When I'm writing smaller files that import a few modules, I'd  prefer to 
>> lump the imports together like this. Doesn't seem like a feature that would 
>> require much effort to implement either.
> 
> I'm fine with this. I'd also like `import as` to handle namespacing 
> simplification and conflict resolution
> 
> `import Bar.Baz as Bif`
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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