Re: [swift-evolution] [Review] SE-0179: Swift `run` Command
> On 17 May 2017, at 20:32, Richard Wei via swift-evolution > wrote: > > Excellent, except that `--chdir` and `--in-dir` are confusing. Why not use a > long, clear name, just like `—enable-prefetching`? Consider `—working-dir` & > `—preexec-working-dir` That would be my one bit of feedback as well. The names of these two parameters aren’t descriptive. My suggestions would be: --working-directory, -w Change working directory before any other operation --run-directory, -r Change working directory before running the executable I don’t believe there’s any reason to shorten or truncate the full parameters if you’re going to offer a single-character alias for them. Otherwise, top proposal! 5 stars, would review again ;) I’m +1 for SE-0179. -t -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Pitch: Omit deprecation warnings for same-file references
Hi Tony,
> On 6 May 2017, at 04:12, Tony Allevato via swift-evolution
> wrote:
>
> These warnings are emitted for any reference to a deprecated entity,
> including those in the same file. In some cases, however, it may be necessary
> and correct to continue referring to the deprecated entity privately while
> discouraging its external use. In these scenarios, the warnings are
> superfluous and generate noise in the build logs. We propose eliminating
> these warnings for references made in the same file.
If same file is the direction that the proposal is leaning toward, what’s
stopping you from creating an internal (or private) implementation that’s not
deprecated. You could then call that via the public, deprecated method/property?
i.e.
```swift
@available(*, deprecated, message: "use 'phoneNumbers' instead")
public var phoneNumber: String? {
get {
return _phoneNumber
}
set {
_phoneNumber = newValue
}
}
private var _phoneNumber: String?
```
Am I missing something that would prevent this from working?
I can see that what you’re proposing would negate the need for the private
backing property/method, but it seems like it’s introducing complexity for the
few times you might need this.
thanks,
Tony
--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/
ABN: 14831833541
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles
> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution > wrote: > > Why? Not trying to be smart, but the reasoning is in Robert’s proposal: >> Their inclusion in the language complicates every part of the compiler >> stack, uses a syntax that can be confused for type annotations >> (https://twitter.com/CodaFi_/status/860246169854894081), contradicts the >> goals of earlier SE's (see SE-0060), and makes non-sensical patterns >> possible in surprising places. Robert, maybe you could include some detail about how this feature is complicating the compiler stack, and what will be improved by it’s removal? That being said, I’m all for you guys making your lives easier at the cost of something we shouldn’t be using in the first place… Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping
Hi Erica, > On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution > wrote: > > Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible > to end-users. Most Swift users will never know anything changed from > S3/SE-0169 but it would support powerful use-cases for people who do serious > coding. I really like this proposal (Flexible Scoping). My one suggestion would be to make it clearer that for the average user, they just keep using the pre-defined access control levels as you’ve mentioned above. I’m a little tired of seeing flexible access control referred to as an anti-goal — everyone has different requirements from this language, and this is the first time I’ve seen something that would potentially cover everybody’s needs without needlessly restricting things to meet one group’s idea of best practice. I’d ask that members of the community please consider that their ideas and needs are not everybody’s ideas and needs when assessing potentially contentious proposals like this one. Personally, I’ve found the conversations around access control on this mailing list draining to the point I’ve unsubscribed from the list a few times. This is the first time I've felt like someone might be on the right track to solving this issue in a future-proof manner, and not just whacking a band-aid on the actual underlying issues. Regardless of the outcome of discussions around this, thank you for the work that Jeffrey and yourself have put into it. I'll +1 the heck out of this proposal if it gets to review. thanks, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Proposal] Nested extensions
Hi Tino, > On 14 Apr 2017, at 19:40, Tino Heth via swift-evolution > wrote: > > This concept tries to avoid all objections that were raised against the > various modells (of course, it triggers fresh ones at the same time ;-), and > because it is purely additive, it removes the pressure to address the current > issues in Swift 4. Sorry to be a (hopefully polite) ogre, but from my perspective, your proposal does not address nor nullify the issues with access modifier levels in Swift, and I don’t think you should be pitching it as a stop-gap. It could make the use of extensions consistent with other similar declarations, but ultimately the access modifier level issues remain. My questions: - Can you clarify for me: does this proposal suggest allowing extensions on the enclosing type to be nested within the type declaration, or within other extensions on the original type? If so, can you please word that more clearly. - I would like to see some examples of the proposed syntax included in your proposal (perhaps via a link to the markdown source on GitHub?). Best case and worst case examples would show what impact it will have on readability and file length when someone goes a bit nuts with this feature. - Do you know how much work will be required to implement this change at this stage? Is it feasible within the bounds of the time remaining before Swift 4’s release? Off-topic suggestion: Using the words “Simply” or “just” when describing work to be done by others is something that you should avoid (unless you’ve already implemented the feature and there’s a PR sitting on GitHub, ready to go). Removing those words allows the sentences to communicate the same ideas, but they no longer trivialise the size/scope of the work to be done during implementation. At this stage, I’m really not sure whether I’d add my support for this proposal were it to go to review, but hopefully my comments are useful. Cheers, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ 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
Hi Tino, > On 8 Apr 2017, at 22:03, Tino Heth via swift-evolution > wrote: > > I wish this would only be a joke, but writing the example, I actually started > liking the concept (but I have a terrible headache right now which might > affect my mind) — so either this receives some feedback, or I might start > re-proposing this ;-) 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. cheers, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Type-based ‘private’ access within a file
Hi Brent, > On 6 Apr 2017, at 09:10, Brent Royal-Gordon wrote: > > So I'm not sure why you're invoking Objective-C to argue that we need a > type-based private. I’m not trying to invoke the ghost of Apple-languages past, seriously :) I was outlining a use-case of something that I could do under Objective-C (and used regularly), and how type-based private (within the same submodule, sure) might be a better answer to that same problem. I’m sorry, I realise I’ve derailed my part of this conversation into a feature request — I’m trying to express that my experience over the past year is that only having private/fileprivate is making it more difficult to maintain some of the larger apps that I work on (the file lengths are getting quite long for common scenarios I could handle more gracefully in the past). Reading that after Swift 4, this will never change has also made me seriously uncomfortable given how much conflicted conversation has occurred on this topic. To me, it sounds like there is a need to address some of the intermediary access levels before this gets locked down permanently, but I’m also just an app developer - I don’t have a rounded Comp Sci understanding of many of the topics being discussed. I’ve had my (rambling, slightly grammatically incorrect) say now, thanks for listening. -t -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Type-based ‘private’ access within a file
> On 6 Apr 2017, at 02:54, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > The developer adds a free function to the file. Or an extension of another > type. Or another type entirely. And they put it in the same file because it > needs to work with the implementation details of the existing type. This is the part of all of these conversations that concerns me deeply. Is the assumption that it is now “best practice” to place all shared implementation into a single file? Aren’t those files going to become quite large in real world use? That’s a terrible thing to encourage! My experience working with protocol conformances in Objective-C over the years is that breaking protocol conformances into categories/extensions on the original type *in separate files* is the best way to keep things small, testable and focused. Separating protocol conformances into separate files, whilst still being able to access private members of the extended type promotes smaller files, and more focused implementation within those files. I know Swift has different purposes for different people here, but ultimately it’s supposed to support great application development for Apple’s platforms, right? To my eyes, `fileprivate` should never have been introduced without some kind of `typeprivate` (similar to how things would be declared back in Objective-C land with a `*+Private.h` header that you could import when it was needed). Right now, there’s no way to duplicate that pattern in Swift - I would need to make anything I wish to access `internal` which exposes it to everything within the application/module - surprisingly, this is a regression from the tooling and access levels I had available in Objective-C. It feels to me like this is one place where it’d be worth considering what common use case prior to Swift would have been. I understand there are people here who don’t use Xcode, and never will - but the vast majority outside this list *will* use Xcode, and will try to follow established patterns set forth alongside AppKit/UIKit/Foundation. If I end up stuck with what the access levels we have now, it’s a regression on what I could do prior to Swift’s introduction. I would ask that the core team consider the existing use cases by the masses of Cocoa programmers out there before locking this design in for eternity - I hope I’m wrong, but it doesn’t feel like that has happened with the access levels we have in v3 or what’s being proposed for v4. I understand the core team wanting to end this circular, draining conversation, but it also feels to me like having a stable ABI/source is a moot point if known, addressable mistakes are locked into that stability. thanks, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Type-based ‘private’ access within a file
> On 4 Apr 2017, at 10:01, David Waite via swift-evolution > wrote: > > I believe we can leave the option open of widening private later as part of a > tasked redesign of access control after Swift 4.0. I’d prefer to not widen > private before we have evaluated access control as a whole, as I believe > private as it is today is the lowest, most restrictive-but-usable level of > access control. Can we get a clear answer from the core team as to whether a redesign of access control is going to be permitted post Swift 4.0? There are a few replies in this thread that are insinuating that no further changes will be permitted. -Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [Review] SE-0159: Fix Private Access Levels
Hi Doug (and list), > What is your evaluation of the proposal? -1 > Is the problem being addressed significant enough to warrant a change to > Swift? No, I also think it is not the _correct_ answer to the actual issues with access control in Swift right now. > Does this proposal fit well with the feel and direction of Swift? With the feel of the proposal, yes. Simplicity is good, less is more and I love that Swift seems to value succinctness where it makes sense. Does the proposal fit with the direction? I would have to say no. Using files as an axis of access control seems wrong to me - ultimately, people seem to be using `fileprivate` as a workaround for the lack of an access level that allows extensions in other files to see members/functions (and some for keeping everything in one file - which seems like quite bad practice to me). `private` (as it is defined right now in Swift 3) actually seems to me to be logical to keep in light of discussions around future work toward submodules. My considered feeling is that if we’re not going to solve the issue of access control holistically - whether by adding other access levels, or by something else like submodules — the change being proposed in SE-0159 seems like shuffling deck chairs on the Titanic. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? Not applicable. My use of other languages is old, out-of-date and not relevant to Swift or this situation. I bring only my Objective-C/Cocoa and Swift knowledge/experience with me this time. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? A fair bit of reading both of the posts to the list, some investigation of features in other languages, then a lot of consternation around actually participating in this conversation. thanks, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] final + lazy + fileprivate modifiers
> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution > wrote: > > We need more examples to make this case. How do we provide those examples? This thread has been actively discussed for close to a week now, so it would be good to do something concrete about it. I think Chris’ second suggestion fits my idea of a reasonable “Default” level of privacy when starting out, and fits the model of progressive disclosure as you so excellently pointed out. Is this something that should go through a proper Proposal? Is someone doing this already? I’d like to help/contribute if it is. thanks, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] final + lazy + fileprivate modifiers
Hi Matthew, > On 17 Feb 2017, at 10:28, Matthew Johnson via swift-evolution > wrote: > > As I have said elsewhere, I think the mental anguish mostly derives from the > fact that scoped private is not the right “default” in a language that uses > extensions pervasively. Chris’s suggestion of having private mean “same file > *and* same type” would be a good default. But if we’re not willing to *also* > have fileprivate then the Swift 2 definition of private is the best > “default’. > > I still think scoped access control is valuable but taking `private` as the > keyword for this was a mistake. I’d like to see us take another stab at > identifying a suitable name for it. That said, I get the feeling that not > too many others have appetite for this so it may be a lost cause… I agree - I’d love to see the current list of controls refined. Personally, (and I understand that everyone has different needs) I see little point to `private` and `fileprivate` as they are implemented in Swift 3. If I have access to edit the source file of a class, what purpose does `private` in Swift 3 even serve? Documentation? Surely there are better ways to come at that issue? Similarly, `fileprivate` means I need to put my extensions in the same file as the original class, leading to unnecessarily large source files. My preference would be replacing `private` and `fileprivate` with “same file and same type” as you mentioned. Ultimately, most of my current use cases that would take advantage of this could be handled by splitting my code into separate frameworks and using `internal`. Cheers, Tony -- Tony Arnold +61 411 268 532 http://thecocoabots.com/ ABN: 14831833541 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops
Just to clarify:
I was +1-ing real world `where` clauses. I am against this proposal.
So… -1 from me on this proposal (and SE-0099 for what it’s worth).
Sorry!
-t
(Thanks for pointing out the confusion my email may have caused, Goffredo)
> On 28 Jun 2016, at 10:39, Tony Arnold wrote:
>
> I wasn’t going to be +1 guy, but “+1”:
>
> I use where pretty heavily across both `if let` and in `for … in` loops.
>
> I find both really readable when formatted, and I’d be disappointed to see
> them go.
>
> I’m super annoyed that I missed (see “wasn’t paying attention during”) the
> review of SE-0099 because I would have loved to see `where` remain usable —
> it reads better than a comma and forces an order to things that made a lot of
> sense to me.
>
> thanks,
>
>
> Tony
>
>
>
>> On 27 Jun 2016, at 18:15, David Rönnqvist via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> We’ve also got two occurrences in our closed source, production code:
>>
>> for (predicate, callback) in predicatesAndCallbacks where
>> predicate(typedEvent) {
>> callback(typedEvent)
>> }
>>
>> and:
>>
>> for conversation in conversations where conversation.state == .Established {
>> }
>>
>> They’re both quite simple and short, but I find them very readable (and I
>> find the first one quite elegant). That said, it wouldn’t be much trouble
>> for us to rewrite these using guard statements or any other construct.
>>
>> - David
>>
>>
>>> On 27 Jun 2016, at 00:47, Russ Bishop via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
On Jun 23, 2016, at 7:14 PM, Erica Sadun via swift-evolution
mailto:swift-evolution@swift.org>> wrote:
> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
> I’m against removing “where" from “for/in”. I use it in my code and I
> think it aids readability quite a bit. In the example:
>
> for x in theArray where x % 2 == 1 { print (x) }
I have used odd-even examples a lot when presenting this concept, and
inevitably the response
is "Whoa, that's cool". What I'm missing are more challenging real-world
use-cases to justify
the construct, and an exploration of why the challenging cases would not
need debugger
support at that point.
My concern (and I am happy to be corrected) is that any code that becomes
slightly more
complex loses the beauty and readability and hinders debugging at the same
time.
— E
>>>
>>> Here are two that are shipping right now.
>>>
>>> for (key, tile) in self._cache where tile.tintColor != self.tintColor { }
>>>
>>> for innerArray in actualValue where innerArray.contains(expectedElement) { }
>>>
>>> Russ
>>> ___
>>> 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
>
> --
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/
Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops
I wasn’t going to be +1 guy, but “+1”:
I use where pretty heavily across both `if let` and in `for … in` loops.
I find both really readable when formatted, and I’d be disappointed to see them
go.
I’m super annoyed that I missed (see “wasn’t paying attention during”) the
review of SE-0099 because I would have loved to see `where` remain usable — it
reads better than a comma and forces an order to things that made a lot of
sense to me.
thanks,
Tony
> On 27 Jun 2016, at 18:15, David Rönnqvist via swift-evolution
> wrote:
>
> We’ve also got two occurrences in our closed source, production code:
>
> for (predicate, callback) in predicatesAndCallbacks where
> predicate(typedEvent) {
> callback(typedEvent)
> }
>
> and:
>
> for conversation in conversations where conversation.state == .Established { }
>
> They’re both quite simple and short, but I find them very readable (and I
> find the first one quite elegant). That said, it wouldn’t be much trouble for
> us to rewrite these using guard statements or any other construct.
>
> - David
>
>
>> On 27 Jun 2016, at 00:47, Russ Bishop via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> On Jun 23, 2016, at 7:14 PM, Erica Sadun via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution
mailto:swift-evolution@swift.org>> wrote:
I’m against removing “where" from “for/in”. I use it in my code and I
think it aids readability quite a bit. In the example:
for x in theArray where x % 2 == 1 { print (x) }
>>> I have used odd-even examples a lot when presenting this concept, and
>>> inevitably the response
>>> is "Whoa, that's cool". What I'm missing are more challenging real-world
>>> use-cases to justify
>>> the construct, and an exploration of why the challenging cases would not
>>> need debugger
>>> support at that point.
>>>
>>> My concern (and I am happy to be corrected) is that any code that becomes
>>> slightly more
>>> complex loses the beauty and readability and hinders debugging at the same
>>> time.
>>>
>>> — E
>>
>> Here are two that are shipping right now.
>>
>> for (key, tile) in self._cache where tile.tintColor != self.tintColor { }
>>
>> for innerArray in actualValue where innerArray.contains(expectedElement) { }
>>
>> Russ
>> ___
>> 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
--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/
