Re: [swift-evolution] Code blocks and trailing closures

[Derrick Ho via swift-evolution]

I don't see any confusion with trailing closures vs if or guard.

If you claim that a long block of 50 lines is hard to digest then that
probably means it needs to be broken down in to smaller pieces.
On Wed, Mar 15, 2017 at 8:27 AM Rien via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 15 Mar 2017, at 13:14, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
> >
> > I still don’t see your point there. In general you won’t look at parts
> of parts of a code. Instead you’ll take a chunk that is valid and not
> ambiguous from the readers perspective.
>
> To me that only works for up to 50 or maybe 70 lines of code. If the
> modules get larger I tend to miss things that are not directly visible.
>
> > Beginners will bump into that issue, because it’s simply meant to be.
> Everyone has to lean the difference between break, continue and return in
> guarded statements and loops. We already have labels to exit specific
> nested loops. Maybe that is also the way return could go?
>
> Maybe, lets wait to see if more people think this is a real problem or not.
>
> Rien.
>
> >
> > Something like:
> >
> > func foo() -> Int {
> >
> > label:
> >
> > [1,2,3,4,5, …].forEach {
> >
> > // Do something
> > // If certain condition is met abort and return from the parent
> scope
> > return(label) 42
> > }
> >
> > return 0
> > }
> >
> >
> >
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> > Am 15. März 2017 um 12:56:31, Rien (r...@balancingrock.nl) schrieb:
> >
> >> Sorry, it seems we are talking past each other, let me try again:
> >>
> >> I left the “if” out on purpose. To show that even though the snippet
> was “valid” code, it was in fact ambiguous.
> >>
> >> With closures (and autoclosures) it becomes possible -to some extent-
> to “enhance” the language.
> >>
> >> Consider:
> >>
> >> guard let c = somefunc() else { showError(); return }
> >> myguard( let c = somefunc()) { showError(); return }
> >>
> >> In this simple example it is clear that the second return behaves quite
> differently from the first.
> >> It gets more difficult if the code in the block cq closure gets very
> large.
> >> Also, I would expect that beginners would have problems understanding
> this (subtile but important) difference.
> >>
> >> Regards,
> >> Rien
> >>
> >> Site: http://balancingrock.nl
> >> Blog: http://swiftrien.blogspot.com
> >> Github: http://github.com/Balancingrock
> >> Project: http://swiftfire.nl
> >>
> >>
> >>
> >>
> >>
> >> > On 15 Mar 2017, at 12:19, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
> >> >
> >> > There is no if … on my screen nor there is one here
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20170313/033888.html.
> May be a typo?
> >> >
> >> > In that case it cannot be a trailing closure because trailing
> closures are banned in such scenarios.
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
> >> >
> >> > As for the lazy variables you’ve mentioned in the original posts, the
> closure there is invoked lately but only once and it cannot be reused at
> all.
> >> >
> >> > Let me know if I understood your gist now.
> >> >
> >> > if someFunction { …; return } // someFunction cannot have a trailing
> closure here!
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Adrian Zubarev
> >> > Sent with Airmail
> >> >
> >> > Am 15. März 2017 um 12:08:19, Rien (r...@balancingrock.nl) schrieb:
> >> >
> >> >> If I wrote this:
> >> >>
> >> >> if serverCert.write(to: certificateUrl) {
> showErrorInKeyWindow(message); return }
> >> >>
> >> >> then the meaning of return would have been different.
> >> >>
> >> >> Imo it is a problem that two pieces of code impact the understanding
> of each other and that those two pieces of code could potentially be very
> far apart.
> >> >>
> >> >> I do agree that the parenthesis are not a perfect solution, it was
> just the first thing that I could think of and that has some level of
> similarity in meaning.
> >> >>
> >> >> Regards,
> >> >> Rien
> >> >>
> >> >> Site: http://balancingrock.nl
> >> >> Blog: http://swiftrien.blogspot.com
> >> >> Github: http://github.com/Balancingrock
> >> >> Project: http://swiftfire.nl
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > On 15 Mar 2017, at 12:00, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
> >> >> >
> >> >> > I’m slightly confused by this. How is a trailing closure different
> from a code block in Swift? It’s basically the same thing with some extra
> syntax sugar because it happens to be the last parameter of your function.
> >> >> >
> >> >> > You can simply write this if you wanted to:
> >> >> >
> >> >> > myFucntion(someLabel: abc, closureLabel: { …; return })
> >> >> >
> >> >> > Parentheses are indicating that your closure is immediately
> invoked.
> >> >> >
> >> >> > let someInt = { return 42 }()
> >> >> > print(someInt)
> >> >> >
> >> >> > let someClosureWhichReturnsAnInt = { return 42 } // You 

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[Derrick Ho via swift-evolution]

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?
On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> Is this a feature or a bug?
>
> class Foo {
> let bar: Int
> init?(someConditionBasedOnInputData: Bool) {
> var localBar: Int = 0
> defer {
> bar = localBar //Cannot assign to property: 'bar' is a 'let'
> constant
> }
> if someConditionBasedOnInputData {
> return nil
> }
> }
> }
>
> It’d be handy to be able to do the assignment upfront in a defer block in
> cases where there’s both a bunch of validation to do on the input data, and
> no harm from assigning the interim values to the final values when you’re
> about to return nil anyway.
>
> - Dave Sweeris
> ___
> 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] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

I'd find it fantastic if they added

var list: String... = 1, 2,3,4,5

However if they remove Variadic arguments then apple would need to remove
it from their apis. To name a few...

print
NSPredicate(format:)
UIAlertView

Removing variadic arguments would be a breaking change though. They would
either need to remove it quickly or deprecate all the methods that use
variadic arguments. Might take awhile before it is removed completely.


On Sat, Mar 11, 2017 at 4:47 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> foo(["a", "b", "c"] as String...)
>
>
> I like this
>
>
> +1
>
>
> I really don't get this:
> We have methods like NSLayoutConstraint.activate(_ constraints:
> [NSLayoutConstraint]), which works with an array, declares its parameter to
> be array and is called with an array. Quite simple.
>
> On the other hand, we have functions which work with an array, but are
> declared with *Type…*, and are called with a comma-separated list of
> elements — and we should add an option to call this function (which works
> on array!) with an array that is decorated with a strange cast?
> That looks extremely awkward to me.
>
> Can I declare a variable like
> var list: String… = "a"
> ?
> Imho it's better to get rid of these odd types completely.
> ___
> 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] Infer types of default function parameters

[Derrick Ho via swift-evolution]

+1

I like that python style shorthand.
On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm always positive with shorthand declarations, though this is a good
> example of ambiguity pron case.
>
> Signatures are signatures. Let's not mess with them.
>
> On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I sent the message below to swift-users@ ~a day ago, but this might be a
> better place to ask and gather some discussion. It is a rather minor
> suggestion and I'm just looking for some opinions.
>
> Declaring a function that has default parameters currently looks like this:
>
> func foo(bar: String = "baz") {
> print(bar)
> }
>
> Now I'm wondering if there would be any problems if it were possible to
> omit the type annotation for default params and let Swift's type inference
> handle that.
>
> func foo(bar = "baz") {
> print(bar)
> }
>
> It feels to be equivalent to omitting type annotations with variable
> declarations. Obviously more complex types would still require annotations
> being specified. Off the top of my head I can't think of any negative
> ramifications this might bring, be it in simple function/method
> declarations or protocol extensions and elsewhere.
> Any further input or examples for situations where this might cause issues
> would be much appreciated :)
>
>
> I like the idea but I'm afraid I don't think I can support it.
>
> I think it is more important for function/method declarations to have as
> explicit a signature as possible; I mean, I'm not even that comfortable
> with the ability to omit -> Void on non-returning functions (I always
> include it just to be consistent).
>
> As others point out, while this makes sense for types where there's only
> one obvious choice to infer, it's not quite so clear on things like ints
> where a function really needs to be absolutely clear on what type/width of
> int it expects, since it's not something you want to have to change in
> future.
>
> One alternative I thought of was an operator for this purpose, e.g- :=
> (chosen since the colon kind of suits the omitted type declaration); this
> would allow a developer to be explicit about wanting Swift to infer the
> type, but it would be inconsistent with regular variables where it's always
> inferred, so I'm not sure if it'd be a good option anyway.
>
> Sorry, I do agree that it feels inconsistent that a function default
> doesn't behave more like a variable's initialisation, but at the same time
> they *are* two slightly different concepts so that's not necessarily a
> bad thing.
> ___
> 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] Allow numerical keywords in member references

[Derrick Ho via swift-evolution]

-1

Something like `42` will make things confusing.


On Thu, Mar 9, 2017 at 5:53 PM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 9, 2017, at 04:40, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I could see a purpose for identifiers which started numbers but weren't
> entirely numerical.
> e.g.
> enum Dimensions { case `2D`, `3D` }
> enum DiceRoll { case d6, `2d6` }
> func roll(dice: DiceRoll) -> Int { ... }
> roll(.`2d6`)
>
> I'm not sure I see one for identifiers which are entirely numerical.
>
>
> That's certainly a much easier sell... How does "_" fit into this? I know
> `123_456` is a valid integer literal and that `_1` is a valid identifier. I
> don't know if `_1` is a valid integer literal.
>
> I'd *like* to support purely numeric identifiers, but I can't think of a
> way around the ambiguity of `3.0`. Maybe only allow it if the enclosing
> type isn't ExpressibleByIntegerLiteral? It feels more than a bit odd,
> though, to have a property name's validity depend on whether or not it's in
> a ExpressibleByIntegerLiteral type.
>
> - Dave Sweeris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Static methods as global functions

[Derrick Ho via swift-evolution]

-1
On Fri, Mar 10, 2017 at 6:18 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> So the topic of global functions like min/max came up on the thread about
> adding a standard clamp method, and it got me to thinking whether there was
> a better way to define most global methods.
>
> Currently for example there are two global functions min and max; very
> useful, and don't make much sense as instance methods, but they're not as
> easily discoverable as a static method declared under relevant type(s). We
> could get around this by defining such functions both as a static method,
> and as a global function, but it means duplicate code and by convention
> only.
>
> An alternative is to remove the need for duplicate methods using a new
> global keyword for a method declaration, telling Swift to define it as both
> a static method *and* a global function. This allows the function to be
> grouped logically under a type, making it a bit neater, but without losing
> the benefit of the global definition. For example:
>
> protocol Comparable {
> global func min(_ a:Self, _ b:Self) -> Self { return a < b ? a : b }
> global func max(_ a:Self, _ b:Self) -> Self { return a > b ? a : b }
> }
>
> With this single definition both of the following are now valid:
>
> let min = Int.min(1, 3)
> let max = max(5, 10)
>
> In the second case, Swift looks at all global definitions for "max" in
> order to locate the best match, leading it to Int.max.
>
> It's a relatively small change, but helps with neatness. It may also be
> good for consistency if we ever get the ability to define operators within
> types (though I'm not sure where we are with that?), as they could
> potentially just use the same format like-so:
>
> struct MyType : Equatable {
> global func == (_ a:MyType, _ b:MyType) -> Bool { /* Determine equality */
> }
> }
>
> I just think it's a neater way to do this than currently requiring
> separate declarations for the static and global versions, especially since
> one usually just calls the other anyway, anyone have any thoughts?
>
> I normally argue against new keywords, but in this case it may be
> justified, as I considered an attribute but it would only end up requiring
> static anyway, so it seemed neater to just have a new category "above"
> static that is both static and global, since a global non-static doesn't
> make any sense. However, one advantage of a @global attribute is that it
> could potentially take a different name for the global function, so I could
> (but probably wouldn't) define something like:
>
> @global("min") static func smallerOfTwo(_ a:Self, _ b:Self) -> Self {
> return a < b ? a : b }
>
> So here, although the method name is smallerOfTwo, it is exposed globally
> as "min". Though I don't know much need there would be for something like
> that.
> ___
> 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] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

Rudolf, I don't believe that is a rule.

One example includes NSLog()

In which the first parameter is a format string and the second is a
variadic argument. The second one can be omitted.
On Wed, Mar 8, 2017 at 5:09 PM Rudolf Adamkovič via swift-evolution <
swift-evolution@swift.org> wrote:

> Correct me if I’m wrong but a variadic argument is guaranteed to have one
> or more elements in the array. Isn’t that the case? As an example, consider
> the following initializer:
>
> public init(state: State, actions: Action...) {
> // ...
> }
>
> Here, I can count on actions to be a non-empty array. It’s
> self-documenting and type-safe. How would this work if arrays are
> (implicitly or explicitly) convertible to variadic arguments?
>
> R+
>
> On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In swift, a variadic argument can become an array without too much effort.
>
> func foo(_ va: String...) {
>let a: [String] = va
> }
>
> However, it seems odd to me that an array can not be converted into a
> variadic argument
>
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
>
> Other people have wondered about this too.
> <http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift>
>
> According to this thread
> <https://devforums.apple.com/message/970958#970958> Doug Gregor says it
> is due to some type ambiguity. with Generics.
>
> If type ambiguity is the issue, Do we have the option to cast it to the
> correct type?
>
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
> to be a type.
>
> What does the community think? Should we be granted some mechanism to turn
> an array into a variadic argument?
>
> ___
> 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] [Draft] Remove support for final in protocol extensions

[Derrick Ho via swift-evolution]

It makes sense since protocol do not allow final. It doesn't make much
sense to allow the extensions to be exempt from this.

Classes that inherit from it can still provide their own implementation of
the supposed "final" protocol method which is contradictory to what final
means.

Protocol extensions should not allow final since the protocol definition
doesn't allow it either.


On Tue, Mar 7, 2017 at 10:23 PM Brian King via swift-evolution <
swift-evolution@swift.org> wrote:

> Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
> this is in scope for Swift 4 since it impacts source compatibility. It's
> not a very exciting proposal, but I think it will help make Swift a little
> more consistent.
>
> https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7
> https://bugs.swift.org/browse/SR-1762
>
> Thanks
>
> Brian
> Introduction
>
> This proposal suggests removing support for the final keyword when
> declaring a function in a protocol extension. The presence of the final 
> keyword
> does not currently generate an error message, and it does not actually
> modify the dispatch behavior in any way.
>
> 
> Motivation
>
> In the original protocol model of Swift, a developer could use the final 
> keyword
> when declaring a function in a protocol extension to ensure the function
> could not be overridden. This keyword has no use in Swift's current
> protocol model, since functions in protocol extensions can not be
> overridden and will always use direct dispatch.
>
> Detailed
> design
>
> The compiler should generate an error or warning when the final keyword
> is used on a function declaration inside of a protocol extension. This is
> consistent with the use of final in structs and enumerations.
>
> Source
> compatibility
>
> This change will impact source compatibility. To maintain compatibility
> with Swift 3, a warning will be generated in Swift 3 mode instead of an
> error message.
>
> Effect
> on ABI stability
>
> This has no effect on ABI stability
>
> Effect
> on API resilience
>
> This has no effect on API resilience
>
> Alternatives
> considered
>
> The only alternative would be to not fix this bug
> ___
> 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] Introducing `Unwrappable` protocol

[Derrick Ho via swift-evolution]

I disagree that the following is better

guard unwrap foo else { ... } // simpler?

It feels like you are re-using foo which previously was an optional but now
is something else. If a variable is a cup, then you'd be reusing a cup that
previously had a different drink in it.

guard let foo = foo else { ... } // current

The current version is preferred since it looks like you are using a new
"cup" to store your non-optional. I like that it is explicit.
On Tue, Mar 7, 2017 at 9:27 PM Greg Parker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth mentioning that the normal let binding can be used for pattern
> matching:
>   let (a, b, c) = foo()
>
> This nicely parallels the existing case syntax:
>   if case let .blah(a, b, c) = bar() { … }
> It would feel inconsistent if the order switched when in a conditional
> binding.
>
> I would prefer that `case` was removed to best mirror the normal syntax,
> requiring `?` or `.some` to be used for optionals
>   if let .blah(a, b, c) = bar() { … }
>   if let unwrapped? = wrapped { … }
>   if let .some(unwrapped) = wrapped { … }
> but I realize this is source-breaking, so I’m happy with the existing
> syntax.
>
>
> We tried `if let unwrapped? = wrapped` some time ago. It was unbelievably
> unpopular. We changed it back.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
> ___
> 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] class indent in swift, history?

[Derrick Ho via swift-evolution]

It might have to do with C history. Anything inside two curly braces
usually had an increased indentation level.

I always thought the switch statement was an oddball for not indenting the
cases.
On Tue, Mar 7, 2017 at 1:42 AM Will Stanton via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Chris and perhaps core team members,
>
> The comments on tab-levels for `switch` made me want to ask about the
> considerations that went into class and protocol-level indentation.
>
> Sorry if my wording isn’t precise, but in Objective-C, functions can
> (should) be at the same 0-indent level as the class:
> @implementation Foo
> // No indent!
> - (void)doSomething {
> }
> @end
>
> However, in Swift, method and nested types are indented by default:
> class Foo : Bar {
> // Things indented!
> enum Types {
> }
> func doSomething() {
> }
> }
>
>
> Was the change mostly driven by the desire for protocol+class+struct+enum
> consistency in ‘increasing’ the scope+indent level? Were there other
> considerations?
> Why didn’t the language evolve into something like this to reduce the use
> of horizontal whitespace, allowing class functions/types at the root/top
> level? Like:
> @class Foo : Bar
> enum Types {
> }
> func doSomething() {
> }
> @end
>
>
> Regards,
> Will Stanton
>
> > On Mar 7, 2017, at 12:52 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I can understand how you might find this unnerving, but it is important
> to understand that Swift and Objective-C/C have different semantics when it
> comes to case labels:  in Swift, a case label *is* a scope, and *is* part
> of the switch statement.  In Objective-C, a case label is just a label,
> like any other goto label: it is not a scope and is not necessarily a
> direct child of the switch statement.
> >
> > C and Objective-C’s behavior is what leads to obscure but important
> things like Duff’s device (https://en.wikipedia.org/wiki/Duff's_device).
> >
> > In contrast, Swift fixes the scoping, fallthrough, and other related
> problems all in one fell swoop, and ensures that cases are directly nested
> under the switch (unlike in C, where they can be nested under other
> statements within the switch).  Because the case/default labels are *part
> of* the switch in Swift, it makes sense for them to be indented at the same
> level.
> >
> > While I can respect that you aesthetically have a preference for the
> Objective-C way of doing things, the rationale for this behavior change
> wasn’t arbitrary and wasn’t due to "LLVM style".  It is an important
> reflection of the core semantics of the language model.
> >
> > Finally, conservation of horizontal whitespace is important for
> comprehension of code, particularly w.r.t. readability and maintenance.
> This is why statements like guard exist: to reduce nesting and indentation,
> directing the attention of someone reading and maintaining code to the
> important parts.
> >
>
> ___
> 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] Should explicit `self.` be required when providing method as closure?

[Derrick Ho via swift-evolution]

[owned self] is weird. [self] is probably better and is currently the way
to explicitly capture a variable.

On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> I think we can stretch it even further. Have an idea in mind.
>
> Automatically propagated self is actually a big issue. Most of the newbies
> do A LOT of mistakes with it. So I thought: what if we restrict it even
> further? Like have no access to self *unless* it's explicitly passed. It
> can be done the very same way we do with [weak self] or [unowned self]?
> What if we introduce [owned self] and remove automatic self propagation?
>
> This way one will have to at least think twice which propagation to choose
> instead of default strong reference which is not that good in many cases.
> Most for me, actually.
>
> If this idea gets any positive feedback and the issue is a headache not to
> me only I'll create a separate thread and/or proposal.
>
> On Sat, 4 Mar 2017 at 21:55 Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is callback an autoclosure, or just a regular argument?
>
> -Kenny
>
>
> On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi list members,
>
> During code review today, I noticed a really subtle memory leak that
> looked like:
>
> self.relatedObject = RelatedObject(callback: relatedObjectDidFinish)
>
> Where `relatedObject` is a strong reference, `callback` is an escaping
> closure, and `relatedObjectDidFinish` is a method of `self`. From a memory
> management perspective, this code is equivalent to:
>
> self.relatedObject = RelatedObject(callback: {
> self.relatedObjectDidFinish })
>
> In the second example, an explicit `self.` is required. It’s my
> understanding that this is to highlight that the closure keeps a strong
> reference to `self`. But, when passing a method, there is no such
> requirement, which makes it easier to accidentally create a retain cycle.
>
> This made me wonder if an explicit `self.` should be required when passing
> a method as an escaping closure. And whether that would help in the same
> way that the explicit `self.` *inside* the closure is intended to.
>
> If it were required, the code in the first example would be:
>
> self.relatedObject = RelatedObject(callback:
> self.relatedObjectDidFinish)
>
> What do you think?
>
> *Alex Johnson*
> ajohn...@walmartlabs.com
> ajohnson on Slack
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

bjc#alternatives-considered>Alternatives
considered

   - Don't change anything.


On Mon, Feb 27, 2017 at 5:35 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> I don't understand the question. It should turn it into a group of
> NSStrings prefixed by a common name. That's how they're imported from
> Objective-C, stripped of their common prefix.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Mon, Feb 27, 2017, at 05:02 PM, Derrick Ho via swift-evolution wrote:
>
> NS_EXTENSIBLE_STRING_ENUM
> Turns a groups of NSStrings into a struct.
>
> What do you suggest for the reverse?
> On Mon, Feb 27, 2017 at 4:39 PM Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> -1 as written due to the impedance mismatch with importing NS_STRING_ENUM
> and NS_EXTENSIBLE_STRING_ENUM. Exporting to Objective-C should export a
> typedef and several constants, not a class. Exporting generated accessors
> to Objective-C is unnecessary as you have -isEqual: and -hashValue on
> NSString over there.
>
> I'm not sure how technically feasible it is to identify "a struct with a
> single field conforming to RawRepresentable" to make it compatible with
> @objc, though I'm not really a compiler person.
>
> Other than that, I like the idea. I don't believe any of the annotations
> to make Objective-C code better in Swift should be one-way.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Sun, Feb 26, 2017, at 01:21 PM, Derrick Ho via swift-evolution wrote:
>
> I updated my proposal
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md>
> to reflect the community's desire to build on @objc instead of adding a new
> attribute @objcstring.
>
> I've included it below for convenience:
>
> Swift Enum strings ported to Objective-c
>
>- Proposal: SE-
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-filename.md>
>- Authors: Derrick Ho <https://github.com/wh1pch81n>
>- Review Manager: TBD
>- Status: Awaiting review
>
> *During the review process, add the following fields as needed:*
>
>- Decision Notes: Rationale
>
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028950.html>
>- Previous Proposal: SE-0033
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/0033-import-objc-constants.md>
>
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#introduction>
> Introduction
>
> We should allow swift-enum-strings and swift-struct-strings to be bridged
> to objective-c. We can use the following notation:
>
> @objc enum Planets: String { case Mercury }
>
> @objc struct Food: String { public static let hamburger = Food(rawValue:
> "hamburger") }
>
> Creating a bridgable version will allow objective-c to enjoy some of the
> benefits that swift enjoys.
>
> Swift-evolution thread: Discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028950.html>
>  Discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032656.html>
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#motivation>
> Motivation
>
> NS_STRING_ENUM and NS_EXSTENSIBLE_STRING_ENUM are annotations that you can
> add to an objective-c global string. The annotations will make swift
> interpret the objective-c global strings as enum and structs respectively
> in theory. But it actually doesn't ever create enums
> <https://bugs.swift.org/browse/SR-3146>.
>
> The problem seems to stem from the conversion from objc to swift. It might
> be more fruitful to make a conversion from swift to objc.
>
> However, what if we take it a step further? Turning a swift-string-enum
> into a bunch of global NSStrings really limits its power. There are many
> classes written by apple that are structs in swift but become classes in
> objective-c (i.e. String becomes NSString, Date becomes NSDate, Array
> becomes NSArray, etc). There is a special bridging mechanism that allows
> this to be possible. I think we should expand on that.
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#proposed-solution>Proposed
> solution
>
> // `@objc` and `String` can be applied to an enum to 

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

NS_EXTENSIBLE_STRING_ENUM
Turns a groups of NSStrings into a struct.

What do you suggest for the reverse?
On Mon, Feb 27, 2017 at 4:39 PM Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 as written due to the impedance mismatch with importing NS_STRING_ENUM
> and NS_EXTENSIBLE_STRING_ENUM. Exporting to Objective-C should export a
> typedef and several constants, not a class. Exporting generated accessors
> to Objective-C is unnecessary as you have -isEqual: and -hashValue on
> NSString over there.
>
> I'm not sure how technically feasible it is to identify "a struct with a
> single field conforming to RawRepresentable" to make it compatible with
> @objc, though I'm not really a compiler person.
>
> Other than that, I like the idea. I don't believe any of the annotations
> to make Objective-C code better in Swift should be one-way.
>
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me
>
>
> On Sun, Feb 26, 2017, at 01:21 PM, Derrick Ho via swift-evolution wrote:
>
> I updated my proposal
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md>
> to reflect the community's desire to build on @objc instead of adding a new
> attribute @objcstring.
>
> I've included it below for convenience:
>
> Swift Enum strings ported to Objective-c
>
>- Proposal: SE-
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-filename.md>
>- Authors: Derrick Ho <https://github.com/wh1pch81n>
>- Review Manager: TBD
>- Status: Awaiting review
>
> *During the review process, add the following fields as needed:*
>
>- Decision Notes: Rationale
>
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028950.html>
>- Previous Proposal: SE-0033
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/0033-import-objc-constants.md>
>
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#introduction>
> Introduction
>
> We should allow swift-enum-strings and swift-struct-strings to be bridged
> to objective-c. We can use the following notation:
>
> @objc enum Planets: String { case Mercury }
>
> @objc struct Food: String { public static let hamburger = Food(rawValue:
> "hamburger") }
>
> Creating a bridgable version will allow objective-c to enjoy some of the
> benefits that swift enjoys.
>
> Swift-evolution thread: Discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028950.html>
>  Discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032656.html>
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#motivation>
> Motivation
>
> NS_STRING_ENUM and NS_EXSTENSIBLE_STRING_ENUM are annotations that you can
> add to an objective-c global string. The annotations will make swift
> interpret the objective-c global strings as enum and structs respectively
> in theory. But it actually doesn't ever create enums
> <https://bugs.swift.org/browse/SR-3146>.
>
> The problem seems to stem from the conversion from objc to swift. It might
> be more fruitful to make a conversion from swift to objc.
>
> However, what if we take it a step further? Turning a swift-string-enum
> into a bunch of global NSStrings really limits its power. There are many
> classes written by apple that are structs in swift but become classes in
> objective-c (i.e. String becomes NSString, Date becomes NSDate, Array
> becomes NSArray, etc). There is a special bridging mechanism that allows
> this to be possible. I think we should expand on that.
>
> <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#proposed-solution>Proposed
> solution
>
> // `@objc` and `String` can be applied to an enum to make it available to 
> objective-c:
> //
> @objc
> public enum Food: String {
>case Calamari
>case Fish
> }
>
> // This can be ported over to Objective-c as an objective-c class
>
> @interface Food: NSObject
>
> @property (readonly) NSString *_Nonnull rawValue;
>
> - (instancetype _Nullable)initWithRawValue:(NSString *_Nonnull)rawValue;
>
> + (instanceType _Nonnull)Calamari;
> + (instanceType _Nonnull)Fish;
>
> @end
>
>
> // `@objc` and `String` can be applied to a struct to make it available to 
> objective-c:
> //
>
> @obj

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

Well, I have found these discussions...

It was marked as a bug <https://bugs.swift.org/browse/SR-128> and then
directed to swift evolution
<https://github.com/ArtSabintsev/swift-evolution/blob/5ef676ec2616465c1cb854f82e3fd4e90b4b09c6/proposals/array-variadic-function.md>
.

@jose, the prefix operator you mention looks good, but in the past
discussions they wanted a postfix operator so that it would match the
declaration.  I think I like the postfix operator.

func foo(_ a: String...) {}

foo(["a", "b", "c"]...) //<- This looks clear.  It is turning the array
into a variadic argument.

However, that thread was closed because it wasn't "discussed" enough prior
making the pull request.

therefore, if people want it, they got to cast their vote in here by either
supporting it or opposing it.

I like my original suggestion since it is more explicit.

foo(["a", "b", "c"] as String...)



On Sun, Feb 26, 2017 at 7:59 PM Jose Cheyo Jimenez 
wrote:

> On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In swift, a variadic argument can become an array without too much effort.
>
> func foo(_ va: String...) {
>let a: [String] = va
> }
>
> However, it seems odd to me that an array can not be converted into a
> variadic argument
>
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
>
> Other people have wondered about this too.
> <http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift>
>
> According to this thread
> <https://devforums.apple.com/message/970958#970958> Doug Gregor says it
> is due to some type ambiguity. with Generics.
>
> If type ambiguity is the issue, Do we have the option to cast it to the
> correct type?
>
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
> to be a type.
>
>
> I think this needs to be done with a spread operator in order to
> disambiguate.
>
> foo(...["a", "b", "c”]
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
>
> I like the idea. Its syntactic sugar so I am not sure how open the core
> team would be to adding it.
>
>
> What does the community think? Should we be granted some mechanism to turn
> an array into a variadic argument?
>
> ___
> 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] Allow trailing argument labels

[Derrick Ho via swift-evolution]

-1 to this proposal.

While it is true that adding the argument labels helps you "read" it
better, you end up with an inverted binary operator.  I'll call it a
sandwich.

Argument labels should be used to name an argument so the fact that there
is no argument provided means that this is not a good use case.

I prefer the work around where you accept a void argument.

func something(_ n: Int, strange: Void) { ... }

Then we people look at the definition they can see that it expects a void!

They can call it like this

something(8, strange: ())

in conclusion, I do not support the original pitch.  Argument labels should
be used for arguments.

On Wed, Feb 22, 2017 at 9:22 AM Haravikk 
wrote:

>
> On 22 Feb 2017, at 13:19, Derrick Ho  wrote:
>
> I've read the pitch, but it isn't clear what the ask is or what benefit it
> would give.
>
>
> The purpose of the feature is to enable selection of identically named
> methods with similar signatures. This came up in the protocol-oriented
> integers debate on the ability to have arithmetic methods with and without
> overflow. Like so:
>
> protocol IntegerArithmetic {
> func adding(_ other:Self) -> Self
> func adding(_ other:Self, reportingOverflow) -> (Self, Bool)
> }
>
> var a = 2, b = 3
> let resultWithoutOverflow = a.adding(b)
> let resultWithOverflow = a.adding(b, reportingOverflow)
>
> Here we have two different methods, one reporting overflow and one
> without, using the label to enable selection, rather than having to have an
> addingWithOverflow() method or similar.
>
> Currently the alternative is to do something like:
>
> enum ReportingOverflow { case .reportingOverflow }
> protocol IntegerArithmetic {
> func adding(_ other:Self) -> Self
> func adding(_ other:Self, _) -> (Self, Bool)
> }
>
> var a = 2, b = 3
> let resultWithoutOverflow = a.adding(b)
> let resultWithOverflow = a.adding(b, .reportingOverflow)
>
> Basically the ability to use the label for method selection is an
> alternative to either defining an enum as above, or having to use a
> different method name.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

gs-ported-to-Objective-c.md#objective-c-name>Objective-c
name

In the above examples, the objective-c name of the class and the swift name
of the class were the same. If this causes a naming conflict then the
objective-c name could be Prefixed with ENUM.

// Swift
@objc
enum Planet: String { ... }

// Objective-c
@interface ENUMPlanet
@end

The programmer should still be able to add their own name by specifying it
as an argument.

// Swift
@objc(CustomPlanet)
enum Planet { ... }

// Objective-c
@interface CustomPlanet
@end

<https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#source-compatibility>Source
compatibility

This will be an additive feature and will not break anything existing.
<https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md#alternatives-considered>Alternatives
considered

   -

   Implement a swift class that implements the above described behviors.
   -

   Don't change anything.


On Tue, Feb 21, 2017 at 6:09 PM Derrick Ho  wrote:

> True.
> In my proposal I mention how NS_STRING_ENUM doesn't produce an swift enum.
>
> So one solution is to merely "go the other way" which would produce what
> Kevin N. suggested.
>
> Is it not odd that that the objc version is so different from the swift
> version?
>
> Would it not be better to offer a somewhat similar API experience between
> the two languages?
>
> @objcstring would "promote" the swift enum to an objective-c class to make
> the API experience similar.
>
> I understand that maybe @objcstring is too niche to get its own
> annotation. Instead @objc should become more powerful.
>
> I think @objc should make an enum become a class with swift-enum like
> abilities. This would allow enum functions to be bridged over to
> objective-c as well.
> On Tue, Feb 21, 2017 at 1:32 PM Michael Ilseman 
> wrote:
>
> A quick note addressing a misconception that you’ll want to clean up for a
> formal proposal:
>
> NS_[EXTENSIBLE_]STRING_ENUMs both generate Swift structs, the difference
> is only in the explicitness of the rawValue initializer. To use the “other
> direction” analogy, you’d similarly want them to apply for rawValue-ed
> structs alone. The reasons are the same: only the structs are
> layout-compatible because enums are integers.
>
> Once you go down this route, perhaps it doesn’t make sense to annotate the
> struct decls themselves anymore. Maybe you just want more @objc control
> over bridging the types. For example, maybe you want to introduce a feature
> so that static members that are layout-compatible with String are bridged
> as global strings with the supplied name.
>
>
>
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
>
> ___
> 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] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

That is an interesting solution.  Haravikk's solution was a breaking change
so it undoubtedly had resistance.

If we were to merely allow Arrays to be cast as type String... then there
were be nothing to break.

String... is technically not a real type though, so when you use it
anywhere outside of a functions argument list, it will not compile.

Maybe we can make a special case?

On Sun, Feb 26, 2017 at 12:25 PM Tino Heth <2...@gmx.de> wrote:

> I suggest to take a look at the topics "Variadics as an Attribute" and "array
> splatting for variadic parameters" and
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
> .
>
> This is basically the other way round (arrays would accept variadic
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with
> types besides array (set, iterator….)
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

In swift, a variadic argument can become an array without too much effort.

func foo(_ va: String...) {
   let a: [String] = va
}

However, it seems odd to me that an array can not be converted into a
variadic argument

foo(["a", "b", "c"]) // <-error
foo("a", "b", "c") // no error

Other people have wondered about this too.


According to this thread
 Doug
Gregor says it is due to some type ambiguity. with Generics.

If type ambiguity is the issue, Do we have the option to cast it to the
correct type?

foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
to be a type.

What does the community think? Should we be granted some mechanism to turn
an array into a variadic argument?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Derrick Ho via swift-evolution]

Does swift still use #?

foo(#)

It might be more obvious then

foo(_)

People might mistake it for foo(_:) if they are just glancing at it.

But foo(#) looks special.
On Thu, Feb 23, 2017 at 1:07 PM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW, I do think the foo(_) is the best variant. For me it means "no
> argument label AND no argument at all, as there is no `:` in it".
> foo(_:) means "no argument label BUT one argument". etc.
> As for `class()` IMO it is too cryptic. class(_) is more clear about what
> it *is*(because of _ as parameters, that symbol is not used when we call
> the func but used when we define a reference to it, like class(_:),
> class(_:something:)
>
> On 23.02.2017 17:36, Ben Rimmington via swift-evolution wrote:
> >
> >> On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
> >>
> >> What happens when you need the backticks for the function name itself?
> We can't nest them.
> >
> > func `class`() {}
> >
> > `class`() // Function call.
> >
> > `class()` // Function reference.
> >
> > -- Ben
> >
> > ___
> > 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: Compound name `foo(:)` for nullary functions

[Derrick Ho via swift-evolution]

The back tick option is interesting. Back tick means "don't treat this as
an expression" which allows us to use keywords in certain areas but have
them. Act as something that isn't a keyword.

let f = `foo()`

However looking at it like this it almost looks like a string.
On Thu, Feb 23, 2017 at 9:16 AM Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote:
>
> *Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently no compound name for a
> function with no arguments.
>
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
>
> Given these four functions, only the first one has no compound name
> syntax. And the simple reference "let myfn = foo" is ambiguous because it
> could refer to any of the four. A workaround is to specify a contextual
> type, e.g. "let myfn = foo as () -> Void".
>
> I filed SR-3550  for this a while
> ago, and there was some discussion in JIRA about it. I'd like to continue
> exploring solutions here and then write up a formal proposal.
>
>
> Would the following be an option?
>
> foo()  // Function call expression.
> `foo()` // Function reference (using backticks).
>
> -- Ben
> ___
> 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/Reality Check] Allow instance members as parameter default values

[Derrick Ho via swift-evolution]

Did you know you can use a static variable as a default parameter?

class poncho {
static var color= "yellow"

func foo(color: String = poncho.color){}
}

I think instance members should not be allowed as default members though.
It may lead to unexpected behavior.
On Wed, Feb 22, 2017 at 11:06 PM T.J. Usiyan via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 if this doesn't have terrible implications.
>
> The downside to making it IUO or Optional is that that changes the type
> signature of  `index(i:offsetBy:)` for no reason other than a default
> value. If you decide to change to or away from providing a default value it
> probably shouldn't change the type accepted in that spot.
>
> On Wed, Feb 22, 2017 at 7:32 PM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 22, 2017, at 10:42 AM, Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Oops, left out that there's this horrifying way of writing it right now:
>
> extension Collection {
> func index(_ i: Index! = nil, offsetBy n: IndexDistance) -> Index {
> let i = i ?? startIndex
> // ...
> }
> }
>
> Nobody wants that.
>
>
> Oh I don’t think it’s all that bad! It also doesn’t need to be an IUO,
> since you’re unwrapping it immediately into another variable no matter what.
>
> This also gives you the flexibility to write this:
>
> extension Collection {
> func index(_ i: Index? = nil, offsetBy n: IndexDistance) -> Index {
> let i = i ?? (n < 0 ? endIndex : startIndex)
> // ...
> }
> }
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Argument labels in callbacks

[Derrick Ho via swift-evolution]

Argument labels on blocks arguments should be brought back.


On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution <
swift-evolution@swift.org> wrote:

> I don’t see why it should be available in function arguments.
>
> The separation of the type and its label makes sense semantically, but the
> syntax doesn’t look as pretty anymore.
>
> Writing something like
>   foo(completion(success:error:): (Bool, Error) -> Void) {}
> seems a bit convoluted to me. We first have to write the labels, then
> remember their order to write the type.
>
> Minor: this also adds additional complexity when Xcode tries to generate a
> stub for the closure, as it needs to find the labels in the function name.
>
> I was thinking of an implementation where closure types could have labels,
> but these could only be used within the body of that closure and would be
> *erased* elsewhere. This however still makes it difficult for the caller
> to figure out what each argument in the closure is representing when using
> foo.
>
> - Franklin
>
> On Feb 22, 2017, at 9:05 AM, Iain Smith via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Would this proposed syntax, using argument labels, also be available in
> function arguments?
>
> e.g
> func items(withCompletion completion(success:error:): ([Item]?, NSError?)
> -> Void) {
>   ...
>   completion(success: items, error:nil)
>  }
>
> On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This was pointed out during the discussions surrounding this proposal and
> it was agreed that the type simplification was important.
>
> There were several suggestions how to bring this back using different
> features - e.g. compound names that would contain the labels. For example:
>
> let callback(success:error:): (Bool, Error?) -> Void = ...
> callback(success: true, error: nil)
>
> This way the type itself wouldn't contain the label information, but the
> name of the variable would.
>
> On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am quite interested in this as well, thanks for bringing it up! It was
> quite disappointing to fall back to multi argument method calls without
> labels as it was going against the emphasis on the value of labels in the
> language as well as decreasing readability of what is supposed to be self
> documenting code.
>
> Sent from my iPhone
>
> On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> When SE-0111
> 
>  was
> approved, I noticed the implication it had when using closures as callbacks:
>
> Writing
>func foo(completion: (success: Bool) -> Void) {
>  completion(success: true)
>}
>
> is no longer possible, because function types can’t have argument labels
> anymore, and the function has to be written:
>func foo(completion: (Bool) -> Void) {
>  completion(true)
>}
>
> which doesn’t look very nice, especially as the number of the arguments
> increases.
>
> After talking to Chris Lattner about this, he referred me to this
> 
>  email.
> I was wondering if there's been any further work or plans in restoring the
> use of argument labels in closures.
>
> - Franklin
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> 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: Compound name `foo(:)` for nullary functions

[Derrick Ho via swift-evolution]

foo(_) seems better. A colon would imply there is an argument of which
there is none.
On Wed, Feb 22, 2017 at 4:52 AM Patrick Pijnappel via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm personally in favor of foo(_), as the number of colons currently
> lines up directly with the number of arguments, and it'd be good to keep it
> that way.
>
> In general though I'm very in favor of requiring the parentheses, as the
> ambiguity between unparenthesized references to functions and properties
> can be quite confusing/annoying.
>
> On Wed, Feb 22, 2017 at 6:35 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On 22 Feb 2017, at 08:05, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Evolutioniers,
>
> *Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently no compound name for a
> function with no arguments.
>
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
>
> Given these four functions, only the first one has no compound name
> syntax. And the simple reference "let myfn = foo" is ambiguous because it
> could refer to any of the four. A workaround is to specify a contextual
> type, e.g. "let myfn = foo as () -> Void".
>
> I filed SR-3550  for this a while
> ago, and there was some discussion in JIRA about it. I'd like to continue
> exploring solutions here and then write up a formal proposal.
>
> To kick off the discussion, *I'd like to propose foo(:) for nullary
> functions.*
>
> Advantages:
> - the colon marks a clear similarity to the foo(bar:) form when argument
> labels are present.
> - cutely parallels the empty dictionary literal, [:].
>
> Disadvantages:
> - violates intuition about one-colon-per-argument.
>
>
> This is a big disadvantage for me and will potentially be very surprising
> for newcomers.
>
> - the parallel between #selector(foo(:))and @selector(foo) is not quite as
> obvious as between #selector(foo(_:))and @selector(foo:).
>
>
> For the sake of discussion, another option would be *foo(_)*. This was my
> original choice, and I like that the number of colons matches the number of
> parameters. However, it's a little less obvious as a function reference. It
> would preclude _ from acting as an actual identifier, and might conflict
> with pattern-matching syntax (although it appears functions can't be
> compared with ~= anyway).
>
>
> This is my favorite syntax so far.
>
> Looking forward to everyone's bikeshed color ideas,
> Jacob
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Derrick Ho via swift-evolution]

I've read the pitch, but it isn't clear what the ask is or what benefit it
would give.
On Wed, Feb 22, 2017 at 8:05 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 22 Feb 2017, at 11:48, Brent Royal-Gordon 
> wrote:
>
> On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> foo.example(foo) // What did I mean here?
> let result = foo.example(foo:) // This looks like I might be trying to
> select a function, rather than call it
>
>
> I think it would be really weird to support not one, but *two* potentially
> ambiguous sugar forms.
>
>
> Those aren't examples I think should be supported, I was thinking out
> loud. The point I was trying to make is that it's not the trailing nature
> that's a requirement, but that the real requirement for this feature to
> work is that there's at least one other, non-Void argument.
>
>
> On another note, one other alternative I did think of for declaration is
> that perhaps it might be better still to use an attribute to specify a
> label-only "argument". Think of it like an attribute on the type, except
> that it specifies that there is no type:
>
> func adding(_ other:Self, reportingOverflow:@labelonly) { … }
>
> The attribute makes it absolutely clear that this is just a label and not
> an actual, functional argument (there won't be a reportingOverflow local
> variable), and that it can be passed without a value when calling this
> method. It'll still need the trailing colon for possible disambiguation of
> variables though.
> ___
> 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] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

True.
In my proposal I mention how NS_STRING_ENUM doesn't produce an swift enum.

So one solution is to merely "go the other way" which would produce what
Kevin N. suggested.

Is it not odd that that the objc version is so different from the swift
version?

Would it not be better to offer a somewhat similar API experience between
the two languages?

@objcstring would "promote" the swift enum to an objective-c class to make
the API experience similar.

I understand that maybe @objcstring is too niche to get its own annotation.
Instead @objc should become more powerful.

I think @objc should make an enum become a class with swift-enum like
abilities. This would allow enum functions to be bridged over to
objective-c as well.
On Tue, Feb 21, 2017 at 1:32 PM Michael Ilseman  wrote:

> A quick note addressing a misconception that you’ll want to clean up for a
> formal proposal:
>
> NS_[EXTENSIBLE_]STRING_ENUMs both generate Swift structs, the difference
> is only in the explicitness of the rawValue initializer. To use the “other
> direction” analogy, you’d similarly want them to apply for rawValue-ed
> structs alone. The reasons are the same: only the structs are
> layout-compatible because enums are integers.
>
> Once you go down this route, perhaps it doesn’t make sense to annotate the
> struct decls themselves anymore. Maybe you just want more @objc control
> over bridging the types. For example, maybe you want to introduce a feature
> so that static members that are layout-compatible with String are bridged
> as global strings with the supplied name.
>
>
>
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
>
> ___
> 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] Let's talk about submodules

[Derrick Ho via swift-evolution]

Oh, I thought this would be another discussion about namespaces.
On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon 
> wrote:
> >
> > Okay, lots of people want to have some kind of submodule feature, so I'd
> like to sketch one out so we can hopefully agree on what submodules might
> look like.
>
> Ten seconds after sending this, I realized I forgot an important caveat: I
> don't expect this to be a feature of Swift 4, no matter how much we might
> want it. I just think that having a design in mind may help inform our
> thinking about access modifiers.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 'Public' class visibility specifiers

[Derrick Ho via swift-evolution]

I've thought about how to deal with override in a way that is consistent
with the language. Maybe something like this?

// publicly visible but can't be subclassed.
public private(subclass)

// publicly visible and may be subclasses within the module. The default
public internal(subclass)

// publicly visible and may be subclasses by all.
public public(subclass)

We also can not forget how it apples to methods

public private(override)
public internal(override)
public public(override)

On Mon, Feb 20, 2017 at 2:12 PM Joanna Carter via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Le 20 févr. 2017 à 19:18, Dimitri Racordon 
> a écrit :
> >
> > Sorry I pressed the wrong button, and the mail was sent right away.
> > I was about to add that I could give it a try, or offer my help.
>
> Since I still haven't worked out how to submit a proposal, if you know how
> to, maybe you should take the lead.
>
> If you want to contact me offline during the preparation, please feel free
>
> --
> Joanna Carter
> Carter Consulting
> ___
> 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] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

I like how the Enum version looks

@objc enum Planet: String {}

But it looks odd for structs

@objc struct Planet: String {}

What do you think we should use?
On Mon, Feb 20, 2017 at 8:05 PM Derrick Ho  wrote:

> Swift Enum strings should not translate into objective c global static
> strings.
>
> As I wrote in my proposal
>
> (
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
> )
>
> , we need to support a failable initializer.
>
> I chose @objcstring to keep it consistent with how it would be used with
> struct for NS_EXTENSIBLE_STRING_ENUM. While an enum can inherit from
> String, a struct does not. So the evidence that this is meant to be used
> for strings is not there. That is why I suggest @objcstring to make that
> explicit and consistent between the two kinds.
>
>
>
> On Mon, Feb 20, 2017 at 7:33 PM Xiaodi Wu  wrote:
>
> Agree. If technical limitations do not prohibit it, Kevin's idea seems the
> more elegant.
>
>
> On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t think we need/want to add `@objcstring` or anything like that, but
> I do think we should let String enums be @objc (currently it’s int types
> only) and imported as const refs.
>
> // Already works
> @objc enum IntEnum: Int {
> case foo = 1
> case bar = 2
> }
>
> // "not an integer type"
> // Should be allowed.
> @objc enum StrEnum: String {
> case foo
> case bar = "baz"
> }
>
> Becomes
>
> // Current
> typedef NS_ENUM(NSInteger, IntEnum) {
> IntEnumFoo = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally initialized const in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
> ___
> 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] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

Swift Enum strings should not translate into objective c global static
strings.

As I wrote in my proposal

(
https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
)

, we need to support a failable initializer.

I chose @objcstring to keep it consistent with how it would be used with
struct for NS_EXTENSIBLE_STRING_ENUM. While an enum can inherit from
String, a struct does not. So the evidence that this is meant to be used
for strings is not there. That is why I suggest @objcstring to make that
explicit and consistent between the two kinds.



On Mon, Feb 20, 2017 at 7:33 PM Xiaodi Wu  wrote:

> Agree. If technical limitations do not prohibit it, Kevin's idea seems the
> more elegant.
>
>
> On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t think we need/want to add `@objcstring` or anything like that, but
> I do think we should let String enums be @objc (currently it’s int types
> only) and imported as const refs.
>
> // Already works
> @objc enum IntEnum: Int {
> case foo = 1
> case bar = 2
> }
>
> // "not an integer type"
> // Should be allowed.
> @objc enum StrEnum: String {
> case foo
> case bar = "baz"
> }
>
> Becomes
>
> // Current
> typedef NS_ENUM(NSInteger, IntEnum) {
> IntEnumFoo = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally initialized const in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

Swift should not forsake objective-c.  At least not when it comes enum
strings.  Although swift enums are suppose to be swift only, I think we
should add a new attribute to slightly relax that.  I think a good
attribute would be @objcstring.

By adding @objcstring, an objective-c exclusive class will be generated.

@objcstring
enum Planet {
  case Jupiter
}

I have written up a proposal with more details on what it would look for
objective-c.

https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md

If no one objects to this proposal I'll submit it.

**notes: I am reviving this discussion so that I may submit this for Swift
4 stage 2
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A concern

[Derrick Ho via swift-evolution]

The first time I read through the swift manual. I thought to myself, "swift
is Apples version of C++"

The book on c -- the C programming language by Brian kernighan -- is around
200 pages.

As for objective c I've yet to see a book that covers more than a single
chapter Before diving into cocoa frameworks.

Big c++ was around 2000 pages, maybe more. Swift's book was around that
size as well. It is huge...

Both are huge. Maybe the ability to be jack of all trades makes for a
dominant language. Kind of like English. It borrows from so many languages
but as a result has universal appeal.

Swift may become modern day c++


On Sun, Feb 19, 2017 at 3:35 PM Dimitri Racordon via swift-evolution <
swift-evolution@swift.org> wrote:

> Very interesting topic!
>
> I disagree with the premise. Without having written a single line of
> Objective-C (nor Cocoa), I was able to get started with Swift in maybe 2
> busy nights. Advanced concepts are difficult to master, but imho the
> learning curve is not that steep.
>
> There are experts in every languages used in the industry, because actual
> production-ready applications often required experts. That is not to say
> that all languages are born equal, but my belief is that if the complexity
> isn’t in the language, then it’s somehow pushed into the libraries. In that
> case, being an expert isn’t really about mastering the language, but rather
> about mastering all the intricacies of its mainstream libraries (J2EE, Ruby
> on Rails, the 10’000’000 libraries required to make something work in
> Javascript, …).
>
> Now I do think it is indeed very important to be careful not to create
> another C++, and I would hate to see Swift going that way. Despite visible
> efforts to keep it at bay, the syntax of the language does look impressive,
> and the countless blog posts on capture semantics prove that memory
> management is not as intuitive as one would think. But judging by the few
> months I’ve been subscribed to this list, I don’t feel like the community
> (or at the very least the users of this list) is heading the way of an "12
> years of experienced minimum required" behemoth.  Additional keywords and
> syntactic constructions are often considered with a lot of prudence, and
> I’m under the impression that a solid 1/2 of the threads end up discussing
> about consistency at some points.
>
> I find it very valuable to receive this great amount of suggestions, and I
> it’d be a little bit sad if everything was simply pushed-back in favour of
> conservatism. These suggestions, and following discussions, allow us to
> constantly reevaluate the consistency and ease-of-use of the language. This
> can be seen as most of the time people end up proposing extensions to
> existing types, or operator overloads.
>
> Best regards,
> Dimitri
>
> ___
> 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] [Draft] @selfsafe: a new way to avoid reference cycles

[Derrick Ho via swift-evolution]

What wrong with [unowned self]
On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> This reminded me of an idea I had long time ago which will have a similar
> effect: add a way to disable implicit captures for closures. FWIW.
>
> > On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > # `@selfsafe`: a new way to avoid reference cycles
> >
> > * Proposal: [SE-](-selfsafe.md)
> > * Authors: [Matthew Johnson](https://github.com/anandabits)
> > * Review Manager: TBD
> > * Status: **Awaiting review**
> >
> > ## Introduction
> >
> > This proposal introduces the `@selfsafe` function argument attribute
> which together with a `withWeakSelf` property on values of function type.
> Together these features enable library authors to create APIs can be
> statically verified to never extend the lifetime of the `self` a function
> they take may have captured.  This is accomplished by allowing the library
> implementation convert the function to a nearly identical function that is
> guaraneteed to have a `weak` capture of `self` and be a no-op after `self`
> is released.
> >
> > Swift-evolution thread: []()
> >
> > ## Motivation
> >
> > Accidentally forgeting to use weak references is a common problem and
> can easily lead to reference cycles.  Some APIs are best designed such that
> users *cannot* extend the lifetime of `self` by escaping a closure that
> happens to strongly capture `self`.  For example,
> `UIControl.addTarget(_:action:for:) does not retain the target, thereby
> preventing users from making the mistake of using a closure with an
> accidental strong reference.  We can do something similar in Swift:
> >
> > ```swift
> > // in the library:
> > func addTarget(_ target: T, action: T -> Int -> Void) {
> >   // store a weak reference to the target
> >   // when the action is fired call ref.map{ action($0)(42) }
> > }
> >
> > // in user code:
> > class C {
> >   init() {
> >  addTarget(self, action: C.takesInt)
> >   }
> >
> >   func takesInt(_ i: Int) {}
> > }
> > ```
> >
> > Both the library and the caller have to deal with a lot of details and
> boilerplate that we would prefer to avoid.  The natural design in Swift
> would be to simply take an action function.  Unfortunately if we do that we
> run into a problem:
> >
> > ```swift
> > // in the library
> > func addAction(_ f: Int -> Void) {
> >   // store a strong ref to f, which might include a strong ref to a
> captured self
> >   // later when the action is fired call f(42)
> > }
> >
> > // in user code
> > class C {
> >   init() {
> >  addAction(takesInt)
> >  // oops! should have been: addAction{ [weak self]
> self?.takesInt($0) }
> >   }
> >
> >   func takesInt(_ i: Int) {}
> > }
> > ```
> >
> > Here the syntax is much nicer, but unfortunately we have unintentionally
> extended the lifetime of `self`.  The burden of ensuring `self` is not
> captured or captured weakly falls on users of the library.
> >
> > It would very nice if it were possible to design an API that has weak
> capture semantics while still acheiving the more concise and Swifty syntax.
> >
> > ## Proposed Solution
> >
> > This proposal introduces a read-only property on all function types:
> `withWeakSelf` as well as a `@selfsafe` function argument annotation.
> (This name for the annotation is a strawman - I would love to hear better
> ideas)
> >
> > ### `withWeakSelf`
> >
> > `withWeakSelf` can be imagined as a property declared like the following:
> >
> > ```swift
> > extension T -> Void {
> >  var withWeakSelf: T -> Void { return // compiler magic }
> > }
> > extension T -> U {
> >  var withWeakSelf: T -> U? { return // compiler magic }
> > }
> > extension T -> U? {
> >  var withWeakSelf: T -> U? { return // compiler magic }
> > }
> > ```
> >
> > It returns a closure that is identical to itself in every respect except
> four:
> > 1. If the context includes a strong or unowned `self` capture, that is
> converted to a weak capture.
> > 2. If the function returns a non-`Void`, non-`Optional` type the return
> type is wrapped in an `Optional`.
> > 3. The function returned by `withWeakSelf` is a no-op after `self` has
> been released.  If the return type is non-`Void`, the function returns
> `nil` after `self` has been released.
> > 4. Any addtional non-`self` context is released as soon as possible
> after `self` is released.
> >
> > From these rules, it follows that `withWeakSelf` can be a no-op unless
> `self` is captured strong or unowned or the return type is non-`Void` and
> non-`Optional`.
> >
> > Important note: any additional context the closure requies beyond `self`
> continues to be captured as it was originally.
> >
> > ### `@selfsafe`
> >
> > When a function argument is annotated with `@selfsafe` two rules are in
> effect for the implementation:
> > 1. The argument *is not* allowed to escape the function.
> > 2. The closure returend by `withWeakSelf`

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Derrick Ho via swift-evolution]

I agree that the current state of bug reporting through radars is
unmotivating.

We file these bug reports and have no idea if it even made a difference.
After seeing this many times we just don't bother with bug reports.

Sure I understand that internally apple uses duplicated issues to show how
often an issue is happening. I guess those numbers motivate an apple
engineer to work on it. Well guess what, those numbers could motivate every
non-apple developer as well! We want to know that our "vote" counts!

Maybe the reason is that apple doesn't want to expose to the world that a
bug exists and therefore keeps it a secret. It is hard to keep bugs a
secret because eventually someone will blog about it or talk about it in a
public MAILING LIST.

I would very much like it if we could see the original bug report and
references to the duplicate reports so we know that our report made a
difference.

Are there down sides to exposing bug reports to the public?

(Sorry for going off topic as well)
On Thu, Feb 16, 2017 at 8:09 AM Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m going OT here, but even though I understand your reasons, you need to
> acknowledge that for developers the rational thing to do is to not file
> radars at all.
>
> Any bug fix will get released at best a few months later and you can only
> actually take advantage of it a few years later (if you care about
> supporting older versions). More realistically we are talking 3-4 years of
> having to work around it (in the best cases). This is a lot of work (with
> almost zero feedback) for some far future benefit that probably will not
> even be relevant to you then.
>
> So to me, when an Apple developer asks me to file a radar, it feels like
> they are asking me to do their job.
>
> I’m sorry for the off-topic rant.
>
>
> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 15, 2017, at 2:25 PM, Charles Srstka 
> wrote:
>
> On Feb 15, 2017, at 3:11 PM, Itai Ferber  wrote:
>
>
> FYI, Tony is the manager of the Foundation team. :)
> We care very much about making sure that the experience of using our
> framework is a positive one — the more Radars we get, the better we can
> prioritize improving APIs that are not working as well as they could be for
> our users. Even if the Radar gets duped to an existing one, thats one more
> +1 for that Radar saying "this is a problem".
>
> Yeah I know, but it’s a frustrating experience, spending a half hour
> writing a detailed bug report (sometimes with videos attached to
> demonstrate the issue), just to effectively do the same thing as spending 5
> seconds to hit the +1 button on most issue trackers you come across.
>
> Especially since you never find out what happened to the original bug
> report. You can see if it’s open or closed, but did they fix it in some
> internal build? Did they decide it “behaves correctly?” Did somebody just
> skim your report, and mistakenly attach it to some other, unrelated issue?
> There’s no way to know.
>
> I will search for your old Radar, but in any case, please do file a new
> one about this, and about any other issues you have, because we are indeed
> listening.
>
> I was pretty sure I'd submitted something way, way back in the misty days
> of yore, but I can’t find it. I’ve filed a couple of new ones:
> rdar://30543037 and rdar://30543133.
>
> Charles
>
>
> Thanks for filing these.
>
> Sometimes, for process reasons, we do indeed mark bugs as dupes of other
> ones. Usually the polite thing to do is to dupe to the earliest filed one.
> Sometimes this comes across with an appearance of not caring to the filer
> of the new bug, but our intent is simply to consolidate the reports we have
> so that we know that the issue is serious.
>
> We do not make API changes without going through a vigorous review
> process, to avoid churn for the many clients above us. The flip side is
> that this can take some time. I’m sure you understand that all software
> engineering is about tradeoffs.
>
> All of that said, we’ll take a look at these and see what improvements we
> can make here. As I said, I’m not a fan of exception-based API.
>
> - Tony
>
>
>
> ___
> 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] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Derrick Ho via swift-evolution]

There is no need to change it

Since the context basically disambiguates the meaning of !

The next best thing is to compare it to false

(val == false) // same as !val
On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> If someone came with a nice syntax I’d be for this. I can’t imagine what
> that would be.
>
> I doubt there is an alternate prefix or postfix operator that would pass
> muster, due to ‘!’ already meaning the appropriate thing in so many
> languages, and swift only supporting symbolic operators.
>
> I can’t think of a method on boolean which would read properly either, e.g.
>
> if isValid.not() {…}
>
> The closest I could think to a decent bike shed color would be a global
> function:
>
> if not(isValid) {…}
>
> -DW
>
> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> So you've identified the problem, but what do you propose as a solution
> here?
>
> It should be noted that a (non-stdlib) language-level answer to this
> question has already been discussed and rejected (
> https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
> ).
>
> ~Robert Widmann
>
> 2017/02/15 9:02、Sadiq via swift-evolution 
> のメッセージ:
>
> Hello,
>
> I would like to suggest to change Logical NOT Operator from ! to something
> else.
> It will increase the readability of the code and will avoid any confusion
> with the symbol used for force unwrapping of optional values.
> It would be easier for new programmers to learn Swift as the first
> language.
> I don't understand the rational behind using the same operator for two
> different purposes.
>
> Thanks and Regards,
> Mohammad Sadiq
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Derrick Ho via swift-evolution]

I think I we can live with the original three: public, internal, and private

Where public is visible to all,
Internal is visible to all within the module, and private is visible only
to the class and the same file.

We can still fulfill the same roles that the current five fill.

Open can become public again.
Public can become final public
Internal remains the same
Fileprivate assimilates into private

Make access control simple again!

On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer 
> wrote:
>
> I know that private was scoped to files before Swift 3.
>
> Fileprivate should obviously be removed because it is, like I said
> previously, just a poor man’s package access level. Yes, private was scoped
> to a file before Swift 3, but at least there wasn’t two kinds of private
> for a single file. Also scoping private to a file makes sense in Swift
> because it plays well with the ability to organize the implementation of a
> type inside of a file into the base type and a number of extensions. I now
> have to use fileprivate in Swift 3 to pull this off while there isn’t a
> requirement for a separate private access level. The fileprivate / private
> distinction also needlessly gets in the way when you want to refactor an
> existing type implementation into base type + extensions, all living in the
> same file.
>
> Anyway, I don’t see a good reason why we should end up with this, once
> sub-modules exist:
>
> open, public, module, fileprivate, private
>
> when we can live with this:
>
> open, public, module, private
>
> and we’re not losing anything that would be significant compared to the
> alternative scenario.
>
>
> Well, there's also internal: open, public, internal, (submodule, however
> it is named), private.
>
> The question being discussed here is whether private should have the old
> or new meaning. I tend to agree with others that the new `private` doesn't
> add much. Modules are a different conversation.
>
>
> Regards,
>
> Dietmar Planitzer
>
> > On Feb 12, 2017, at 18:16, Xiaodi Wu  wrote:
> >
> > What was added in Swift 3 was `private`; the old `private` was renamed
> `fileprivate` with no change in behavior. Certainly, submodules are a big
> topic that deserves careful consideration. But the question being discussed
> here is about rolling back the change that was implemented in Swift 3 by
> removing `private` and restoring `fileprivate` to its old name.
> >
> >
> > On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Fileprivate is a feature that should not have been added to Swift 3
> because it is in the end just a needlessly limited version of the Java
> package access level. Fileprivate forces me to put all types which are
> related on an implementation level into the same file while Java packages
> allow me to put each type implementation into a separate file. The only
> thing that Java requires is that all files which are part of the same
> package are tagged with the same package id. Java’s package access level is
> more powerful than fileprivate because it gives me more freedom in how I
> want to organize my code while still making sure that code in sibling and
> parent packages can not access symbols inside my package which form part of
> the implementation details of my package.
> >
> > The first thing that needs to happen before any more access levels are
> added is that a concept of sub-modules is added to Swift along the lines of:
> >
> > 1) modules can be organized into a tree with one module as the root.
> >
> > 2) all modules which are nodes in the same module tree form a single
> resilience domain.
> >
> > IMO, the sub-module stuff should be designed similar if not the same way
> as Java packages because there are already lots and lots of SDEs who know
> how Java packages work, and Java packages are well understood, simple and
> straight-forward in their mechanics.
> >
> > Once sub-modules are in place, it makes sense to revisit the access
> level topic. Eg in order to add a “module” access level that represents the
> scope of a module. So “module” could then do what file private can do today
> plus more. But we should stop trying to add more access level to the
> language until then. We also need to look much more at the bigger picture
> of things instead of getting too much hung up on a single component of a
> larger mechanism, when it is that larger mechanism that is primarily
> interesting and relevant.
> >
> >
> >
> > Regards,
> >
> > Dietmar Planitzer
> >
> > > On Feb 12, 2017, at 16:16, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
> > >
> > > I vehemently agree on these points. New-private and fileprivate "[add]
> more information" to a file the same way requiring `self.` and other sorts
> of visual noise that Swift normally eschews.
> > >
> > > I wish for the Swift community to be i

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Derrick Ho via swift-evolution]

I find the final keyword useful when I want to communicate that this class
should not be subclassed.

I think the behavior should remain the same since it is useful.

On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 12, 2017, at 3:52 PM, Xiaodi Wu  wrote:
>
> On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson 
> wrote:
>
>
> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu  wrote:
>
> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson 
> wrote:
>
>
> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't
> actually meaningful. Here's why:
>
> If I see `fileprivate` and can understand that to mean "gee, the author
> _designed_ this member to be visible elsewhere inside the file," then it's
> actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee,
> the author mashed some button in his or her IDE," then it's not really
> telling me anything.
>
>
> You’re looking at it backward.  It’s when you see `private` and can deduce
> “this member is only visible inside it’s declaring scope” that can be
> really helpful.  *This* is what matters.
>
>
> In what ways can that information help you?
>
> What you've said above, as I understand it, is that it's not currently
> meaningful to see `fileprivate` because the migrator is writing it and not
> the author. The improved approach you proposed is the additional warning.
> In that case, the compiler will help to ensure that when I see
> `fileprivate`, at least I know it's necessary. But that's only telling me a
> fact (this member is accessed at least once outside the private scope), but
> it's still machine-based bookkeeping, not authorial intent.
>
>
> The important thing is that this machine-based bookkeeping results in a
> proof about the code.  This facilitates reasoning about the code.  You can
> make an argument that this proof is not important enough to matter, but you
> must admit that this is a real concrete gain in information that is
> immediately available to a reader of the code (after they know that it
> compiles).  Personally, I find this proof to be valuable.
>
>
> Comparison has been made to `let` and `var`. In that case, whether a
> variable is mutated can be non-trivial to deduce (as Swift has no uniform
> scheme for distinguishing mutating from non-mutating functions; the ed/ing
> rule has many exceptions). By contrast, here, I don't see any gain in
> information. You can literally *see* where the (file)private member is
> accessed, and when a file gets too long, even a simple text editor can do a
> decent enough find.
>
> If you're right that the real value is that seeing `private` helps you
> reason about the code, then that value must be commensurate to how often we
> see Swift users amending the migrator to take advantage of it. For me, the
> compelling evidence that Swift users don't find this proof to be valuable
> is that, by examination of Swift 3 code, Swift users haven't bothered. If
> we add a new fix-it to force them to, then of course they'll mash the
> buttons, but it's pretty much declaring that they are wrong not to care
> about what it seems they do not care at present.
>
>
> This is really subjective and it’s not clear to me that there is
> substantial evidence one way or another.  I know that `private` is valued
> and used heavily by the teams I have worked with.
>
>
> It wasn't a rhetorical question that I asked: what value do you perceive
> in the new `private` in terms of helping you reason through code?
>
>
> You are right that any time it really matters it’s not hard to answer the
> question with a search, so it’s largely a convenience.
>
> That said, I find it quite useful to be able to mark helper methods and
> types within an extension `private` to make it clear that they are indeed
> local helper methods or types that are not accessed more broadly.  This
> communicates an intent.  As long as your extensions don’t get too large, a
> whole extension is usually visible on a single screen on a 27” iMac which
> is very useful - you don’t have to consider code that is scrolled out of
> sight.
>
> I also find it useful to be able to mark stored properties `private` and
> therefore *not* available to extensions.  This can facilitate tighter
> encapsulation of state, especially when there is a handful of basis methods
> through which the extensions access that state.
>
>
> Maybe that’s an exception, but maybe not.  I don’t think we know yet and I
> think this is what Chris is hoping to learn.
>
>
> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner  wrote:
>
> I don't fully agree: you are right that that is the case when writing
> code.  However, when reading/maintaining code, the distinction is
> meaningful and potentially important.
>
> -Chris
>
> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu  wrote:
>
> If the overwhelming use case is that developers s

Re: [swift-evolution] for in? optionalCollection {

[Derrick Ho via swift-evolution]

let test: [Int]? = nil
for b in test ?? [] where b != 42 {
   Print(b)

}

I don't think you need new syntax since what you want can be accomplished
quite succinctly already


On Sat, Feb 11, 2017 at 8:18 AM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

for i in test ?? [] {
print(i)
}

For a more general solution, we could add Optional.flatten() to support
optional sequences:

for i in test.flatten() {
print(i)
}

​
___
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] Access level control on setter

[Derrick Ho via swift-evolution]

Just for the sake of completeness... :)

open open(set) var open_open = ""i
open public(set) var open_public = ""
open internal(set) var open_internal = ""
open fileprivate(set) var open_fileprivate = ""
open private(set) var open_private = ""
public public(set) var public_public = ""
public internal(set) var public_internal = ""
public fileprivate(set) var public_fileprivate = ""
public private(set) var public_private = ""
internal internal(set) var internal_internal = ""
internal fileprivate(set) var internal_fileprivate = ""
internal private(set) var internal_private = ""
fileprivate fileprivate(set) var fileprivate_fileprivate = ""
fileprivate private(set) var fileprivate_private = ""

private private(set) var private_private = ""

On Fri, Feb 10, 2017 at 12:36 PM Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> How about just using this?
>
> struct MyType {
> public fileprivate(set) var timestamp: Date
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 10. Februar 2017 um 18:33:35, Pasquale Ambrosini via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hi guys,
> My idea is simple, put an access level control token to the setter of a var
>
> Right now, we are likely to do something like this in order to hide the
> setter:
>
> fileprivate var _timestamp: Date = Date()
>
>
> public var timestamp: Date {
> return self._timestamp
> }
>
> The idea is to do it without using another var, like this:
>
> public var timestamp: Date {
> get { return self._timestamp }
> fileprivate set(newValue) { _timestamp = newValue }
> }
>
> In this way the setter will be available “locally” in the file but it will
> not be accessible from outside.
> The only problem that I can see is how to reference the var itself? As you
> can see I used  “_timestamp” like Objective-C, but there should be another
> way to do reference it.
>
>
> Cheers,
>
> Pascal
>
>
>
>
>
>
> ___
> 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] Is it possible to compile swift code to dynamic library ?

[Derrick Ho via swift-evolution]

If you use the "swiftc" command it will create an executable. Maybe there
is a command in there to create linker files which you can offer to your c
project.

Any one on this threat super knowledgeable on the "swiftc" command?
On Thu, Feb 9, 2017 at 1:53 AM Zheng Ping via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Compile swift code to dynamic library(a *.so file which is compatible with
> C), and let the *.so file can be linked directly by a pure C project.
>
> --
> with kind regards
> ___
> 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] Warning when omitting default case for imported enums

[Derrick Ho via swift-evolution]

-1
I prefer to have enums enforce that all cases are met otherwise use a
default value.


If an API changes and adds new cases I want to know about it so that I can
do something about it! If we hide it then weird and mysterious bugs might
creep up
On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via swift-evolution <
swift-evolution@swift.org> wrote:

> That's awesome. It looks like `(planned) Open and closed enums` is
> exactly what I'm looking for.
>
> Would it help if I created a concrete proposal for that or is it something
> the Swift team already has brewing?
>
> Sent from my iPhone
>
> On Feb 7, 2017, at 22:01, Michael Ilseman  wrote:
>
> BTW, this will likely be part of the eventual design of “open”/resilient
> enums ala
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums.
> There, the goal is to reduce both ABI and source breakage caused by this
> sort of thing. It seems like for your purposes, you’re less inclined to
> care about ABI breakage than source breakage, though that may change in the
> future.
>
>
>
> On Feb 7, 2017, at 7:12 AM, Tanner Nelson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swift Evolution,
>
> I'd like to propose that a warning be emitted when default cases are
> omitted for enums from other modules.
>
> What this would look like:
>
> OtherModule:
> ```
> public enum SomeEnum {
> case one
> case two
> }
>
> public let global: SomeEnum = .one
> ```
>
> executable:
> ```
> import OtherModule
>
> switch OtherModule.global {
> case .one: break
> case .two: break
> ^ ⚠︎ Warning: Default case recommended for imported enums. Fix-it:
> Add `default: break`
> }
> ```
>
> Why:
>
> Allowing the omission of a default case in an exhaustive switch makes the
> addition of a new case to the enum a breaking change.
> In other words, if you're exhaustively switching on an enum from an
> imported library, the imported library can break your code by adding a new
> case to that enum (which the library authors may erroneously view as an
> additive/minor-bump change).
>
> Background:
>
> As a maintainer of a Swift framework, public enums have been a pain point
> in maintaining semver. They've made it difficult to implement additive
> features and have necessitated the avoidance of enums in our future public
> API plans.
>
> Related Twitter thread:
> https://twitter.com/tanner0101/status/796860273760104454
>
> Looking forward to hearing your thoughts.
>
> Best,
> Tanner
>
> Tanner Nelson
> Vapor
> +1 (435) 773-2831
>
>
>
>
>
>
>
> ___
> 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] define backslash '\' as a operator-head in the swift grammar

[Derrick Ho via swift-evolution]

I have found it strange that operator characters are the only ones that may
be used as operators. Sometimes Characters that look like operators are not.

Why does there need to be a divide?

Why can't an arbitrary set of characters become operator-ized?

For example some people would like "and" to become a binary operator and
use it instead of "&&"

If we had the ability to define an operator out of any set of characters I
think it would make the swift language a lot better.

Is there a technical reason why?


On Tue, Feb 7, 2017 at 2:36 AM David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> And the overjoyed operator: \o/
>
> On 7 Feb 2017, at 08:04, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I really have nothing to add to this discussion, except for this fun fact:
> apparently, the backslash was added to ASCII so you could write /\ and \/
> operators: http://www.bobbemer.com/BACSLASH.HTM
>
> Slava
>
> On Feb 5, 2017, at 7:29 AM, Nicolas Fezans via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and \
> used otherwise within the swift code will be interpreted as an operator or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.
>
> Nicolas
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Derrick Ho via swift-evolution]

I don't like the idea of for-else since it doesn't really add much value.
It hardly saves you any typing.

-1
On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Fri Feb 03 2017, Dimitri Racordon  wrote:
>
> Talking of Python, Swift is not Python and the argument not to
> implement a feature because its semantics conflict with the semantics
> of a similar looking feature in another language is bogus.
>
>
> I don't have a anything to say about for-else, but just a comment on the
> meta-point of how we evaluate designs: precedent set by other languages
> affects learnability, and is one of the criteria we've always considered
> when designing Swift.
>
>
> Two things:
>
> 1. Somehow the quoting in your email has got messed up so it looks like a
> statement I made was made by somebody else who may or may not agree with
> the sentiment expressed.
>
> 2. You’ve never been shy of going against precedent if you consider it to
> be a *bad* precedent. Otherwise Swift would still have C style for loops
> and pre/post increment/decrement operators. That is as it should be. The
> Python for … else statement is a mess. My brief survey of the Internet
> suggests it is confusing even to some Python programmers. It should not be
> allowed to prevent the Swift team from implementing similarly named but
> better designed features if there are other good reasons for doing so.
>
>
> This is not at odds with what you’re saying, but I wanted to add that
> there’s a difference between *removing* syntax and having *conflicting* 
> syntax.
> That is, not having a for-else loop is fine, but having a for-else loop
> that behaves differently than Python’s would require a pretty strong
> reason. As far as I know there’s only one place where we deliberately chose
> to conflict with another language’s precedent, and that’s '…' being an
> inclusive range (where it is the exclusive range operator in Ruby), and
> that discussion led to us picking '..<‘ instead of ‘..’ for the other
> operator.
>
> Jordan
>
>
> And despite disliking the updated .../..< operators at first, I find it
> has increased
> inspectability and clarity at the point of use. Good call in my opinion.
> Similar behaviors and outcomes should adopt conventional syntax unless
> an updated syntax offers measurable benefits.
>
> -- E
>
> Mildly interesting reference:
> https://mail.python.org/pipermail/python-ideas/2009-October/006155.html
>
>
>
>
> ___
> 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] define backslash '\' as a operator-head in the swift grammar

[Derrick Ho via swift-evolution]

If the \ operator is not defined in swift, does it treat it as something
that can be operator overloaded?


On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> wrote:

> Dear all,
>
> This is a rather simple proposal to add '\' (backslash character) as a
> valid operator-head in the swift grammar.
>
> One argument for it, is that there exist a backslash operator in the
> MATLAB/Scilab/Octave languages. In this languages A\B solves the linear
> system A*X = B for X (or the least square problem associated to it if the
> system of equations is overdetermined). I am doing some numerical
> computation in Swift and it would be nice to be able to declare the same
> operator name for this functionality.
>
> I might have missed some arguments for not adding them, but I seems to me
> that until now the \ character is only used inside of string literals. If
> that is the case, both uses should never generate a conflict or be
> ambiguous, isn't it? (String literals keep their interpretation of \ and \
> used otherwise within the swift code will be interpreted as an operator or
> as the beginning of an operator)
>
> I am curious to see what will be the feedback on this.
>
> Nicolas
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Derrick Ho via swift-evolution]

I agree with you on point number two. There is way too much scrolling. Im
viewing it on mobile so that's even more scrolling. Discourse allows
jumping to the next topic so if I don't want to scroll I can jump to the
next topic.
On Sat, Feb 4, 2017 at 2:36 PM Cihat Gündüz via swift-evolution <
swift-evolution@swift.org> wrote:

> After trying out Nate Cook’s Discourse test server
>  I’d like to add a few things on my
> previous message:
>
> #1 I found the beginning of this threads discussion
>  
> without
> any problems (both from navigating through the threads structure and from
> the search feature) which was interesting for me, as I couldn’t do that in
> my mail client given that I opted in to the mailing list later on.
> Especially the fact that at the beginning Discourse wasn’t even suggested
> of the original post was interesting. I wouldn’t have known that without
> the Discourse test server.
>
> #2 Following a discussion is much easier in general, but I noticed one
> downside (I guess that’s one of the hurdles to be addressed): Some quotes
> within emails were imported to threads in a way that makes reading actually
> much worse. See this thread
>  as an example.
> The initial messages is repeated over and over again, and since it’s very
> long scrolling all the time is really annoying here.
>
> #3 I really like the fact that Discourse makes it very simple to get an
> overview of all the current discussion threads. For example, I opened the 
> Swift
> Evolution  category and
> could see immediately all threads that I’m aware of since I saw new
> messages coming in my inbox – but many more, that I wasn’t aware of where
> discussion seem to have cooled down for a while. That’s really convenient!
>
> Mostly following the discussion is much simpler on Discourse, so my
> previous claim that it would solve all my problems seem to be true. I’d
> really like to see this getting to Discourse. Then I would even be able to
> send my fellow Swift developers links to discussions and they would
> actually read them – this would improve the quality of our internal best
> practice discussions a lot.
>
> --
> Cihat
>
> Am 4. Februar 2017 um 16:13:32, Ben Rimmington via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>
> > On 26 Jan 2017, at 18:02, Nate Cook wrote:
> >
> >> On Jan 25, 2017, at 3:32 PM, Douglas Gregor wrote:
> >>
> >> I’ve looked into Discourse a bit, and it does look very promising. One
> *specific* way in which a motivated individual could help would be to take
> a look at Discourse’s import scripts and try importing swift-evolution’s
> mailing archives with them. We absolutely do not want to lose history when
> we switch technologies. Do the messages import well? Are threading and
> topics maintained in a reasonable manner? Does Discourse provide effective
> UI for looking into past discussions on some specific topic we’re
> interested in?
> >
> > ✋
> >
> > I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem
> dependencies, and sed-cleaned mbox files to try this out—you can see the
> results of an import (using one or two day old data) at this address:
> > http://discourse.natecook.com/
>
> Discourse doesn't properly import names with an acute accent:
>
> 
> 
>
> I'm not sure why "=?utf-8?Q?F=C3=A9lix_Cloutier?=" isn't automatically
> decoded by the Mail library:
>
> <
> https://github.com/discourse/discourse/blob/f1e7bca3c92ea57f69e6ebb19f7fc75f188ab953/script/import_scripts/mbox.rb#L202-L205
> >
> <
> https://github.com/mikel/mail/blob/5d9e3441b3efdee4c283093ab2872d017258b62d/lib/mail/fields/common/common_address.rb#L43-L47
> >
> <
> https://github.com/mikel/mail/blob/5d9e3441b3efdee4c283093ab2872d017258b62d/lib/mail/elements/address.rb#L80-L88
> >
> <
> https://github.com/mikel/mail/blob/5d9e3441b3efdee4c283093ab2872d017258b62d/lib/mail/encodings.rb#L99-L118
> >
>
> -- Ben
>
> ___
> 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] Annotation of Warnings/Errors

[Derrick Ho via swift-evolution]

I feel like warnings showing up as you type are an IDE's responsibility.

Annotations to delay warnings seem like noise.  Once you get used to
programming you don't need the annotations.

If warnings are bothersome, then turn it off in the Xcode settings!




On Thu, Feb 2, 2017 at 1:34 PM Pierre Monod-Broca via swift-evolution <
swift-evolution@swift.org> wrote:

+1 to the proposal
+1 to teach how to remove live issues to beginners, so they have a chance
to train at detecting errors without the compiler



Pierre

Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> a écrit :

+1

On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

One of the biggest issues that I saw while teaching Swift to newbies (most
had not programmed before) is confusion based on the early warnings/errors
that swift/xcode gives you as they type.  What would happen is that they
would type a variable, and it would say… “You haven’t used this variable”
and so they would just click the fixit because they trust the compiler more
than they trust themselves.  This would lead to a point where they were
very confused because some of the code was code they had thought through,
and some of it was changed by random fixits in ways they didn’t understand…
and so it would lead to more errors/fixits until they had errors which
couldn’t be fixed.


Imho this is the best example to illustrate that inflationary use of
warnings does more harm than good, and I hope it will be fixed.

Having a bunch of conditions for warnings looks like overkill to me, and
there are alternatives:
- Only show when building
- Only show in release builds
- Linter

That said, I'm going out on a limb and claim I already know how to write
code and don't need basic schooling, and showing warnings before I hit
compile is merely a distraction.

But there are also Playgrounds which seem to be an important aspect of
Swift, especially for newbies who could really benefit from some hints.
There are no linters, no release builds, and even no regular builds for
Playgrounds, so your model is the only one that works for them.

Bottom line:
+1

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


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

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

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

[Derrick Ho via swift-evolution]

Shouldn't NSUInteger always become UInt in swift?
On Thu, Feb 2, 2017 at 12:07 AM Freak Show via swift-evolution <
swift-evolution@swift.org> wrote:

> I have a framework I wrote that maps Objective C objects to sqlite records
> - deriving sqlite schema definitions from property definitions.  You simply
> derive model classes from my base class Model and the base class will
> introspect the properties and handle all the sql for you.  A little like
> CoreData but the property definitions are used for the meta model instead
> of an external model file and it is a lot leaner and natural feeling.
>
> I picked NSUInteger for the auto incremented primary key because, after
> all, it would never go negative.
>
> However, when I tried to import this framework into Swift and use Model as
> a base class for a Swift class, I found it nearly impossible to satisfy the
> compiler about mixed mode comparisons and ultimately changed the type to
> NSInteger.
>
> I was not happy about it and if I wasn't the framework author I would have
> thought harder about changing it.
>
>
>
>
> On Feb 1, 2017, at 17:29, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *find out how Objective-C projects are using NSUInteger in their headers:*
>
> - Do they have no NSUIntegers at all?
> - Are they using NSUInteger because they’re overriding something that used
> NSUInteger, or implementing a protocol method that used NSUInteger?
> - Are they using NSUInteger as an opaque value, where comparisons and
> arithmetic are uninteresting?
> - Are they using NSUInteger as an index or count of something held in
> memory?
>
>
> ___
> 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] for-else syntax

[Derrick Ho via swift-evolution]

Maybe we can add a new parameter "otherwise" to the forEach method

[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})
On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm of two minds on this feature; I kind of support the idea of the
> construct, especially because there are some behind the scenes
> optimisations it can do, and it can look neater.
> However, I'm not at all keen on the re-use of else; if there were a better
> keyword I might suppose that, for example "empty" or something like that,
> but nothing I can think of feels quite right.
>
> I mean, when it comes down to it the "best" way to write the loop is like:
>
> var it = names.makeIterator()
> if let first = it.next() {
> print(first)
> while let current = it.next() { print(current) }
>
> } else { print("no names") }
>
>
> However this is a horrible thing to do in your own code, especially if the
> loop body is larger than one line, but is just fine if it's done behind the
> scenes for you (complete with unwrapping of the iterators if their type is
> known).
>
> Which is why I kind of like the idea of having the construct itself;
> otherwise, like others, I use the less "correct" option like so (for
> sequences):
>
> var empty = true
> for name in names { print(name); empty = false }
> if empty { print("no names") }
>
>
> At which point I simply hope that the compiler optimises away the
> assignment (since it only actually does something on the first pass).
>
> So yeah, I can see a use for it, but I'd prefer a construct other than
> for/else to do it; at the very least a different keyword, as there's the
> possibility we could also have a while/else as well and it would need to be
> very clear, which I don't feel that for/else is.
>
> On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> ah! I forgot about the break semantics, that’s definitely one for the con
> list.
>
> I like Nicolas’ solution, clear to read.
>
> On 1 Feb 2017, at 18:18, Nicolas Fezans  wrote:
>
> I tend to write this kind of treatment the other way around...
>
> if names.isEmpty {
> // do whatever
> } // on other cases I might have a few else-if to treat other cases that
> need special treament
> else {
> for name in names {
> // do your thing
> }
> }
>
>
>
> This only works if you know the size of the sequence before you start
> iterating it. You can, for example, iterate a lazy sequence and calculating
> its size before iterating it defeats the object.Thus for { … } else { … }
> where the else block only executes if the for block was never executed does
> have some utility.
>
> However, I am not in favour adding it. The same functionality can be
> achieved by counting the number of iterations and testing the count
> afterwards (or by using a boolean). It takes a couple of extra lines of
> code and an extra variable, but I think that is a Good Thing. It’s more
> explicit and (as the Python example shows) there could be hidden subtleties
> that confuse people if for … else … is badly designed. Also, in many cases,
> I would argue that treating the zero element sequence differently to the n
> > 0 element sequence is a code smell. About the only use-case I can think
> of off the top of my head is UI presentation e.g. “your search didn’t
> return any results” instead of a blank page.
>
> Talking of Python, Swift is not Python and the argument not to implement a
> feature because its semantics conflict with the semantics of a similar
> looking feature in another language is bogus. I don’t see the Python for …
> else being different (and having looked it up to see what you all were
> talking about, my opinion is that the Python for … else is a disaster) as
> being a legitimate con to this cleaner and more logical idea in Swift.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Derrick Ho via swift-evolution]

Does Discourse allow stuff to be "plus-one-ed"? I like how Reddit has this
feature and I notice that many people on this mailing list either -1 or +1
something.

I feel like it is very democratic.
On Mon, Jan 30, 2017 at 10:52 AM Rudolf Adamkovič via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for either e-mail or GitHub issues. No need for yet another tool...
>
> R+
>
> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm surprised there is so little support for JIRA. Anyone think it's a bad
> tool for the job?
> On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I haven't yet seen a good answer to the question: who is going to put in
> the long-term commitment to host and maintain a replacement solution,
> moderate forums, make technical upgrades and backups, and perform all the
> other maintenance and administrative work it takes to properly run a system
> like Discourse, a web forum, or even a bug tracker.
>
>
> I will volunteer to be a moderator of the Swift forums. I have time
> available, and the core team surely has better things to do.
>
> Nevin
> ___
> 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
>
>
> Personally, I’d prefer if we used GitHub Issues. I like keeping the
> current state of the project together with the known issues in it. It also
> has better formatting and actually supports some kind of syntax
> highlighting for Swift code.
>
> I just assumed that some of our requirements (e.g. syncing with Apple’s
> internal “radar” system) disqualified it.
>
> The reason why we don’t have topics every month about migrating our
> bug-tracking system is that JIRA (while perhaps not optimal) is at least
> passable. That’s more than you can say for the mailing lists, most of the
> time.
>
> - Karl
> ___
> 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] The lack of namespaces is leading people astray

[Derrick Ho via swift-evolution]

If you make a dynamic framework called APIFramework
And add a public class called URL_ME

You can instantiate it with APIFramework.URL_ME() from your project.


I haven't tried to see if this would work with global variables but I
assume it would.
On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> I submitted a proposal with TJ a while ago that tried to address this
> comprehensively because the trouble is if you just want submodules you have
> to define how our current penta-scheme of access control interacts with
> each level or do away with a few of them to make some simplifying
> assumptions.  It also raises an ambiguity with qualified imports that has
> to be worked out.
>
> On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If I remember correctly it has been said that we don't need namespaces in
> favor of submodules, which schould solve these issues.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> The lack of namespaces is making people create all kinds of "design
> patterns".
>
> struct API {
> static let endpoint = "http://example.com/api";
> }
>
> Here is an "improvement" to the above "design pattern" to prevent
> instantiating API:
>
> struct API {
> private init() {}
> static let endpoint = "http://example.com/api";
> }
>
> Finally, here is another "improvement" that uses enum instead of struct to
> avoid having to write the private initializer:
>
> enum API {
> static let endpoint = "http://example.com/api";
> }
>
> I doubt any of you find this beautiful. Yet these "design patterns" (just
> hacks IMO) are spreading like the plague because of the lack of namespaces.
>
> What do you think?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

[Derrick Ho via swift-evolution]

The answer is simple, it becomes ambiguous about whether it should get the
var or the function pointer

Suppose we could do this

let r = 5
func r() {}

If we call r, should we get 5 or should we get ()->()


On Mon, Jan 30, 2017 at 4:21 PM Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> I used to believe this was a problem, but once I internalized the idea
> that this ugliness was a signal to choose better variable and property
> names, it has ceased to be an issue for me and in fact, IMO, has become an
> asset of the language.
>
> l8r
> Sean
>
>
> > On Jan 30, 2017, at 3:17 PM, Jaden Geller via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I personally find it kind of weird that `let x = 0; do { let x = x + 1
> }` is disallowed but `let x: Int? = 0; if let x = x { }` is allowed. The
> former case requires you first rename the variable you plan to shadow,
> inconveniently:
> >
> > ```
> > let x = 0
> > do {
> >   let tempX = x // ew
> >   let x = tempX + 1
> > }
> > ```
> >
> >> On Jan 30, 2017, at 11:56 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> This seems like it’s running through the same check that disallows
> defining and calling a closure
> >>
> >> let randomFunc : () -> () = randomFunc()
> >>
> >>> On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> Example that does not compile:
> >>>
> >>>let randomArray = randomArray(withCapacity: 4096)
> >>>
> >>> Compiler error: “Variable used within its own initial value”
> >>> The variable name unfortunately clashes with the function name.
> >>>
> >>> This problem forces the developer to think about an alternative name.
> >>> IMHO that’s suboptimal since many times the most canonical naming
> would be one where these two go by the same name.
> >>>
> >>> It’s not a big problem in practice but I wonder if there are plans to
> change this?
> >>>
> >>>
> >>> Thanks,
> >>> Michael Gubik
> >>>
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

[Derrick Ho via swift-evolution]

Boris,

My Intent is to make it easier to develop dependency B. I may want to
develop on a feature branch for dependency B so I'd like to use PM to force
that to happen.

I don't want to have to cd into the A folder and then cd into B to make
that change. I want to control the whole thing from the root git repo
On Fri, Jan 27, 2017 at 1:55 PM Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> This is an obvious (and much needed) enhancement!
>
> While co-developing an application and a dependency package it’s annoying
> having
> to create ‘dummy’ git tags to keep SPM happy.
>
> -g.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Derrick Ho via swift-evolution]

I'm surprised there is so little support for JIRA. Anyone think it's a bad
tool for the job?
On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I haven't yet seen a good answer to the question: who is going to put in
> the long-term commitment to host and maintain a replacement solution,
> moderate forums, make technical upgrades and backups, and perform all the
> other maintenance and administrative work it takes to properly run a system
> like Discourse, a web forum, or even a bug tracker.
>
>
> I will volunteer to be a moderator of the Swift forums. I have time
> available, and the core team surely has better things to do.
>
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Derrick Ho via swift-evolution]

I don't like mailing lists since it is very easy to forget about a topic.
What I noticed about mailing lists is that the most controversial topics
live the longest. I think swift-evolution should be able discussing the
stuff that matters for the future of swift.

I think the best choice for that would be JIRA.

The whole swift evolution process can be better streamlined with this tool.
Each proposal goes through different states from development, to awaiting
review, to being approved or rejected.

We can make JIRA a part of the swift-evolution process. By incorporating
the process as part of the workflow. The Jira board allows everyone to see
what stage a proposal is in. You can see which have been rejected,
approved, or defered.

Each proposal can be written as part of a single JIRA story where the story
can be modified after getting feed back. With mailing lists, you need to
pile the most recent thing on the top and hope no one is replying to old
content. The formatting is quite standard and we won't run into weird
formatting issues. People can comment on the issue at hand and not get
lost. People can reference other JIRA tickets which get turned into
clickable links. People can reference other people. This helps when you are
trying to tell one specific person something and not everyone.

JIRA allows you to search for stories. In our case it will be proposals and
we will find an easier time seeing what stage it is in.

Speaking of stages, did everyone know that we are on Swift 4 stage 1? I
didn't I thought we were on swift 3 stage xyz. We can name each board after
the current swift version and stage. Often times a story is not appropriate
for stage 1 and should be discussed again in the next stage. the JIRA board
can be given the current Swift version and stage and anything that needs to
be pushed back can move to a "re-evaluate in next stage" status. Once the
new stage is set, we can simply move the story back in for discussion.

I may not be the best at describing the best parts of JIRA, but i believe
it may make the whole swift evolution process easier.

In summary we should use JIRA because
* Story can be updated.
* No loss in context
* Google searchable
* Story Statuses (i.e. discuss, review, approved, implemented.etc)
* Standard UI
* Stories can reference each other
* Easy sign up
* email support
* attachments

Anyone else +1 JIRA?


On Thu, Jan 26, 2017 at 1:33 PM Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

I'm actually convinced that I'd rather use an email client. Having to
participate in a web app is a regression in my experience.

Daniel Duan
Sent from my iPhone

On Jan 26, 2017, at 10:15 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

Awesome :) Hopefully that will finally convince the people what ‘are
working on this’ to actually make it ;)

I could find some really old threads of mine in just seconds. My mail
client cannot do that job that well.

Cannot wait 🤤

-- 
Adrian Zubarev
Sent with Airmail

Am 26. Januar 2017 um 19:03:13, Nate Cook via swift-evolution (
swift-evolution@swift.org) schrieb:


On Jan 25, 2017, at 3:32 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:


On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

I have no problem with the project moving to forums instead of the Mailman
mailing lists we have now — if it is the right set of tradeoffs.

My preference is to approach the topic objectively, working from goals and
seeing how the mailing lists are aligning with those goals and how an
alternative, such as Discourse, might do a better job.

The current use of mailing lists has been carry-over of how both LLVM does
public discussion (which is all mailing lists) and how the Swift team at
Apple has used mailing lists for discussion.  That inertia has benefits in
that it is a familiar workflow that is “proven” to work — but the doesn’t
mean it is the best option going forward.

Here are some of the things that matter to me:

- Topics are easy to manage and search, with stable URLs for archives.

- It is easy to reference other topics with a stable (canonical) URL that
allows you to jump into that other topic easily.  That’s hard to do if you
haven’t already been subscribed to the list.

- Works fine with email clients, for those who want to keep that workflow
(again this inertia is important).

- Code formatting, and other tools that add clarity in communication, are a
huge plus.

I’d like to understand more the subjective comments on this thread, such as
"may intimidate newcomers”.  This feels very subjective, and while I am not
disagreeing with that statement I don’t fully understand its
justification.  Signing up for mailing lists is fairly straightforward, and
one isn’t obligated to respond to threads.  Are forums really any less
“intimating”? If so, why is that the case?  Is this simply a statement
about mailing lists not being in vogue?

I do al

Re: [swift-evolution] Optional Assignment Operator

[Derrick Ho via swift-evolution]

-1

On Wed, Jan 25, 2017 at 1:11 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch 
> wrote:
> >
> > Really? My observation from a quick test is that "a? = b" assigns b to a
> if a already has a value, or does nothing if it's nil. This is sort of the
> opposite of what's being proposed, which is that "a ?= b" should assign to
> a only if it does NOT have a value.
>
>
> My mistake, I misread the proposal. What Nichi appears to be suggesting is
> an assignment that only happens when `b` has a value. I would hesitate to
> spell that `?=` since that's so similar to '? =', but perhaps it's useful,
> though there are many ways to spell that already.
>
> -Joe
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

[Derrick Ho via swift-evolution]

It probably is a good idea.

Perhaps the changes can be done in the Package.swift file but allow nesting
of dependencies.

Suppose your dependency is like this where P is your current project

P --> A --> B

Normally P we would describe its dependency on A while B would be
abstracted away. In A, there would be another Package.swift file describing
its dependency on B.

However if we add the ability to NEST the dependency graph in P's
Package.swift it could serve as an override to the default behavior.

import PackageDescription

let package = Package(
name: "P",
targets: [],
dependencies: [
.Package(url: "https://blah.com/A.git";,
majorVersion: 1, depdencies: [
.Package(url: "https://blahblah.com/B.git, branch: "test")
]),

]
)


On Tue, Jan 24, 2017 at 3:28 PM Daniel Dunbar via swift-evolution <
swift-evolution@swift.org> wrote:

> I am reposting this since the URLs were mangled in the original email.
>
> Hello Swift community,
>
> The review of SE-0149 “ Package Manager Support for Top of Tree
> development" begins now and runs through January 31, 2017. The proposal is
> available here:
>   https://github.com/apple/swift-evolution/blob/master/proposals/
> 0149-package-manager-top-of-tree.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>   https://lists.swift.org/mailman/listinfo/swift-build-dev
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
> More information about the Swift evolution process is available at
>   https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
> - Daniel
>
> Review Manager
>
> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hello Swift community,
>
> The review of SE-0149 “ Package Manager Support for Top of Tree
> development" begins now and runs through January 31, 2017. The proposal is
> available here:
>
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposal
> 
> s/*0149-package-manager-top-of-tree.md
> *
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> - Daniel
>
> Review Manager
> ___
> swift-build-dev mailing list
> swift-build-...@swi

Re: [swift-evolution] Fixing raw enum types

[Derrick Ho via swift-evolution]

enum Something: RawRepresentable {

}

Generics?
On Mon, Jan 16, 2017 at 1:51 PM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> This idea by Karl made me branch off a new thread.
>
> 2017-01-16 21:28 GMT+03:00 Karl Wagner :
>
> It would be helpful for synthesised RawRep conformance. The
> inheritance-like syntax we have now is awful - it makes people think that
> RawRepresentable is some kind of magic protocol that will allow special
> compiler jango to happen.
>
> You could see why they think that. This looks very much like the enum is
> going to *be* an Int32:
>
> enum Something: Int32 {
> case oneThing = 36
> case anotherThing = 42
> }
>
> This is also one of the icky parts to allowing tuples of integer/string
> literals (something people ask for quite a lot). It would look like you’re
> deriving your enum from a non-nominal type:
>
> enum Something: (Int32, Int32) {
> case oneThing = (3, 12)
> case anotherThing = (5, 9)
> }
>
> Even if Swift gains newtype, it’s not that case. The enum does not gain
> methods or behavior of the specified type. It’s just a shorthand, hinting
> the compiler to provide correct RawRepresentable conformance.
>
> I suggest to invent a new syntax for this type hinting for
> RawRepresentable. For example, it can be an annotation:
>
> @raw(Int32) enum Something {
> // ...
> }
>
> Or a contextual keyword:
>
> enum Something : raw(Int32) {
> // ...
> }
>
> Perhaps, he most uniform and explicit of syntaxes:
>
> enum Something : RawRepresentable {
> case oneThing = 36
> case anotherThing = 42
> }
>
> enum AnotherThing : RawRepresentable {
> typealias RawValue = Int32
> case oneThing
> case anotherThing
> }
>
> ​
> ___
> 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] Equatability for enums with associated values

[Derrick Ho via swift-evolution]

I think it is better to create a syntax for getting the associated values
and then comparing them.

enum Option {
case foo(String)
case bar(Int)
case zip
}

let op = Option.foo("hello")
let bb = Option.foo("world")

// proposed tuple-like syntax

op.foo.0 // returns Optional("hello")

// then we can compare values directly

if op.foo.0 == bb.foo.0 {
// ...
}

On Fri, Jan 13, 2017 at 5:44 PM Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 13, 2017, at 2:30 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 13, 2017, at 15:10, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That seems pretty close to Rust’s derive. Why not invent a similar syntax
> in Swift? Otherwise it will make us look through all the sources to make
> sure deriving is used.
>
> enum Option: @derive Equatable {
> ...
> }
>
> Also, we can get better looking compilation errors, like:
>
> ERROR at line 1, col 14: could not derive Equatable for Option
> enum Option: @derive Equatable {
>  ^
>
>
> I think that idea came up once before... can't remember where, though, or
> what we thought of it at the time.
>
> As far as reducing enum boilerplate, what about borrowing the generic
> system's syntax and looking at it from the switch's PoV?
> func == (lhs: MyEnum, rhs: MyEnum) -> Bool {
> switch  (lhs, rhs) {
> case (c(let lVal), c(let rVal)): // both lhs and rhs are "c" and the
> same case
> return lVal == rVal //syntax error if `==` isn't defined for the
> associated value types of every case
> default: return false
> }
> }
>
>
> I think initially, we would like to implement deriving these witnesses
> directly in the compiler, instead of trying to come up with a
> metaprogramming syntax for them.
>
> Slava
>
>
> - Dave Sweeris
> ___
> 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] Update on the Swift Project Lead

[Derrick Ho via swift-evolution]

Have fun working at Tesla Mr Chris Lattner!

I look forward to seeing tesla car apps that can be written in swift.
On Wed, Jan 11, 2017 at 1:22 PM Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 11 Jan 2017, at 18:18, John Pratt via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > You are just going to drop this entire project, that has its name
> associated with you,
> > for a very fierce competitor?
> >
>
> That’s pretty insulting to everybody else who works on the project
> (including the many contributors here).
>
> Besides, it’s just plain wrong. Swift is a tool, and like any other tool
> it is judged on its intrinsic merit for a job, regardless of whichever
> names may be attached to it.
>
> > However capable Ted Kremenek is, and I am sure that is, you have
> collectively decided
> > to break this programming language every year or so.
> >
> > Who is going to get behind this programming language now that it is
> associated with
> > a turncoat?
>
> We have contributors from IBM, Microsoft, Uber and/or Lyft, maybe also
> from Facebook (not sure), Apple (obviously), and probably more. I don’t
> think they all decided to invest time in making Swift better because Chris
> Lattner told them he would always work at Apple. So chill.
>
> > ___
> > 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] Consolidate Code for Each Case in Enum

[Derrick Ho via swift-evolution]

Interesting proposal Tim. So instead of repeating the enum cases multiple
times we repeat the functions multiple times?

I feel like this merely flipping the complexity but not really getting rid
of it.
On Tue, Jan 10, 2017 at 8:08 PM Tim Shadel via swift-evolution <
swift-evolution@swift.org> wrote:

> OK. I've taken the most recent changes from this thread and put together a
> draft for a proposal.
>
> https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562
>
> I'd appreciate your review, especially to ensure I've covered all the
> important scenarios. I've taken the 3 associated value scenarios (none,
> unlabeled, labeled) and shown them in each example (calculated value, func,
> default, error). I've included the raw text below, without any syntax
> highlighting.
>
> My big question is: does the error case in the last example affect ABI
> requirements, in order to display the error at the correct case line? I
> assume it doesn't, but that's an area I don't know well.
>
> Thanks!
>
> Tim
>
> ===
>
> # Enum Case Blocks
>
> * Proposal: SE-
> * Authors: [Tim Shadel](https://github.com/timshadel)
> * Review Manager: TBD
> * Status: **TBD**
>
> ## Motivation
>
> Add an optional syntax to declare all code related to a single `case` in
> one spot. For complex `enum`s, this makes it easier to ensure that all the
> pieces mesh coherently across that one case, and to review all logic
> associated with a single `case`. This syntax is frequently more verbose in
> order to achieve a more coherent code structure, so its use will be most
> valuable in complex enums.
>
> Swift-evolution thread: [Consolidate Code for Each Case in Enum](
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029966.html
> )
>
> ## Proposed solution
>
> Allow an optional block directly after the `case` declaration on an
> `enum`. Construct a hidden `switch self` statement for each calculated
> value or `func` defined in any case block. Use the body of each such
> calculated value in the hidden `switch self` under the appropriate case.
> Because switch statements must be exhaustive, the calculated value or
> `func` must be defined in each case block or have a `default` value to
> avoid an error. Defining the `func` or calculated value outside a case
> block defines the default case for the `switch self`. To reference an
> associated value within any of the items in a case block requires the value
> be labeled, or use a new syntax `case(_ label: Type)` to provide a
> local-only name for the associated value.
>
> ## Examples
>
> All examples below are evolutions of this simple enum.
>
> ```swift
> enum AuthenticationState {
> case invalid
> case expired(Date)
> case validated(token: String)
> }
> ```
>
> ### Basic example
>
> First, let's add `CustomStringConvertible` conformance to our enum.
>
> ```swift
> enum AuthenticationState: CustomStringConvertible {
>
> case invalid {
> var description: String { return "Authentication invalid." }
> }
>
> case expired(_ expiration: Date) {
> var description: String { return "Authentication expired at
> \(expiration)." }
> }
>
> case validated(token: String) {
> var description: String { return "The authentication token is
> \(token)." }
> }
>
> }
> ```
>
> This is identical to the following snippet of Swift 3 code:
>
> ```swift
> enum AuthenticationState: CustomStringConvertible {
>
> case invalid
> case expired(Date)
> case validated(token: String)
>
> var description: String {
> switch self {
> case invalid:
> return "Authentication invalid."
> case let expired(expiration):
> return "Authentication expired at \(expiration)."
> case let validated(token):
> return "The authentication token is \(token)."
> }
> }
>
> }
> ```
>
> ### Extended example
>
> Now let's have our enum conform to this simple `State` protocol, which
> expects each state to be able to update itself in reaction to an `Event`.
> This example begins to show how this optional syntax give better coherence
> to the enum code by placing code related to a single case in a single
> enclosure.
>
> ```swift
> protocol State {
> mutating func react(to event: Event)
> }
>
> enum AuthenticationState: State, CustomStringConvertible {
>
> case invalid {
> var description: String { return "Authentication invalid." }
>
> mutating func react(to event: Event) {
> switch event {
> case let login as UserLoggedIn:
> self = .validated(token: login.token)
> default:
> break
> }
> }
> }
>
> case expired(_ expiration: Date) {
> var description: String { return "Authentication expired at
> \(expiration)." }
>
> mutating func react(to event: Event) {
> switch event {
> case let refreshed as TokenRefreshe

Re: [swift-evolution] Update on the Swift Project Lead

[Derrick Ho via swift-evolution]

Thanks Chris! Thanks to yours work we got an improved objc and swift.
On Wed, Jan 11, 2017 at 4:33 AM Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> Good news for Chris and Ted, I guess, congrats guys :)
>
> I am wondering, what’s the future of Playgrounds, now that it’s main
> ‘driver’ left Apple?
> Playgrounds is definitely one early killer app for Swift, it would be a
> pity for the project to stagnate.
>
> -g.
>
> PS: I am also wondering if Tesla will start using some Swift now ;-P
>
> >
> > One thing that I don’t think is fully appreciated by the community: Ted
> has been one of the quiet but incredible masterminds behind Swift (and
> Clang, and the Clang Static Analyzer) for many years.  His approach and
> modesty has led many to misunderstand the fact that he has actually been
> running the Swift team for quite some time (misattributing it to me).
> While I’m super happy to continue to participate in the ongoing evolution
> and design of Swift, I’m clearly outmatched by the members of the Apple
> Swift team, and by Ted’s leadership of the team.  This is the time for me
> to graciously hand things over to folks who are far more qualified than
> me.  Swift has an incredible future ahead of it, and I’m really thrilled to
> be small part of the force that helps guide its direction going forward.
> >
> > -Chris
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Cancelable named defer statements

[Derrick Ho via swift-evolution]

Its probably better to use a Boolean variable close_file to "cancel" it,
rather than change the entire language.

func openFile(kind: String) -> UnsafeMutablePointer? {

var file = fopen("MyFile.txt", "r")
var close_file = true
defer { if close_file { fclose(file) }} // <--

if fileIsNotValid(file) { return nil }

if fileDoesNotContainsData(file, kind) { return nil }

if fileDataOutOfDate(file) { return nil }

// Prevent the deferred handler from closing the file
   close_file = false // <--

return file
}

On Sat, Jan 7, 2017 at 1:20 PM Rien via swift-evolution <
swift-evolution@swift.org> wrote:

> Is there any interest in a proposal to introduce a named defer statement
> that can be cancelled?
>
> Lately I find myself writing this kind of code:
>
> func openFile(kind: String) -> UnsafeMutablePointer? {
>
>
> var file = fopen("MyFile.txt", "r")
>
>
> var closeFile = true
>
> defer { if closeFile { fclose(file) } }
>
>
> if fileIsNotValid(file) { return nil }
>
> if fileDoesNotContainsData(file, kind) { return nil }
>
>
> if fileDataOutOfDate(file) { return nil }
>
>
> // Prevent the deferred handler from closing the file
> closeFile = false
>
> return file
> }
>
> Which imo would be much cleaner if we were able to write:
>
> func openFile(kind: String) -> UnsafeMutablePointer? {
>
> var file = fopen("MyFile.txt", "r")
>
> CLOSE_FILE: defer { fclose(file) }
>
> if fileIsNotValid(file) { return nil }
>
> if fileDoesNotContainsData(file, kind) { return nil }
>
> if fileDataOutOfDate(file) { return nil }
>
> // Prevent the deferred handler from closing the file
> cancel CLOSE_FILE
>
> return file
> }
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> ___
> 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 draft] Use obtain let instead if let construction

[Derrick Ho via swift-evolution]

*if let *is fine the way it currently is.  It may be strange to newcomers
since it is unique, but once you get used to it, it is super useful.

On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> I quite really like the `if let` syntax, feels natural to me.
>
> -1
>
> ___
> 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] Consolidate Code for Each Case in Enum

[Derrick Ho via swift-evolution]

Currently we can write a helper method to aid in getting the values inside
the enum associated value.  Below is a fully working implementation:

```

enum Package {

case box(String, Int)

case circular(String)

var associated: Associated {

return Associated(package: self)

}

struct Associated {

let box: (String, Int)?

let circular: (String)?

init(package: Package) {

switch package {

case .box(let b):

box = b

circular = nil

case .circular(let b):

box = nil

circular = b

}

}

}

}


let b = Package.box("square", 5)

b.associated.box?.0 // Optional("square")

b.associated.box?.1 // Optional(5)

b.associated.circular // nil


let c = Package.circular("round")

c.associated.box?.0 // nil

c.associated.box?.1 // nil

c.associated.circular // Optional("round")
```

I had to wedge in a special type called "Associated" and had to write some
boiler-plate code to get this effect.  It is quite predictable and can
probably be done under the hood.  I would of course prefer syntactic sugar
to simplify it and turn
```
b.associated.box?.0
```
into
```
b.box?.0
```

On Sun, Jan 8, 2017 at 1:05 PM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 8, 2017, at 06:53, Karim Nassar via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One area of enums that I’d love to see some sugar wrapped around (and
> perhaps this has already been discussed previously?) is extracting
> associated values.
>
> There are many times where, given an enum like:
>
> enum Feedback {
> case ok
> case info(String)
> case warning(String, Location)
> case error(String, Location)
> }
>
> I’d love it if we could tag the associated values with some semantic
> accessor, perhaps borrowed from tuples:
>
> enum Feedback {
> case ok
> case info(msg: String)
> case warning(msg: String, loc: Location)
> case error(msg: String, loc: Location)
> }
>
> then:
>
> let foo = self.getSomeFeedback() // -> Feedback
> if let msg = foo.msg { // since not all cases can hold a ‘msg’ .msg is an
> Optional
> print(foo)
> }
>
>
> Can't remember if it's come up before, but +1. I can't count how many
> times I've written something like:
> enum Foo : CustomStringConvertible {
> case c1(T1)
> case c2(T2)
> ...
> case cN(TN)
>
> var description: String {
> switch self {
> case .c1(let val): return "\(val)"
> case .c2(let val): return "\(val)"
> ...
> case .cN(let val): return "\(val)"
> }
> }
> }
>
> Being able to simplify that to:
> var description: String {
> let nilDesc = "some appropriate description"
> return "\(self.0 ?? nilDesc)"
> }
>
> Would be great.
>
> - Dave Sweeris
> ___
> 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] Eliminate tuples - unify member access syntax

[Derrick Ho via swift-evolution]

On Jan 7, 2017, at 23:37, Derrick Ho  wrote:


I think pattern matching is the most compelling reason to keep tuples.


If they were gone, how would we replace the following?


switch (a, b) {

case (value1, value2):

case (value3, value4):

}



I really have to ask.  What do you use this for?  In general iPhone
application programming I have never wanted or needed to do that.  I do
some AudioUnits as well.  Still never needed it.


The alternative would be something like this
```
if a == value1 && b == value2 {
} else if a == value3 && b == value4 {
}
```

You would end up repeating boilerplate code.  Plus, the switch statements
guarantee that all cases are exhaustive while using a bunch of
if-statements would not.  A switch statement would force you to provide a
default case if you did not cover all the cases, but an if-statement
doesn't stop you.

Exhaustive switch statements are popular among low-level C programming
people that work with micro-controllers like Arduino.  I believe one of
swifts goals is to enter that territory.

On Sun, Jan 8, 2017 at 1:49 PM David Sweeris  wrote:

>
> On Jan 8, 2017, at 09:33, Freak Show  wrote:
>
> On Jan 7, 2017, at 22:51, David Sweeris  wrote:
>
>
> A really convenient way to pass around multiple values without having to
> bother with a formal struct.
>
>
> That's actually a big part of my concern.
>
> The people on this list are, I'm certain, among the top programmers
> working.
>
> I'm more worried about what happens when average (which IME means barely
> competent) developers get going with this.  I suspect nobody will ever
> declare a struct again.
>
>
> Doubtful, since tuples can't have any computed properties, functions, or
> conform to protocols.
>
> Type declarations are valuable - they are an opportunity to express
> intent.  OTOH, a pair of ints is a pair of ints and if all pairs of ints
> are type compatible then opportunities for catching errors drop if
> developers start favoring anonymous tuples over former structs.
>
>
> I don't think they are... "(Int, Int)" (without labels) will type-check to
> any pair of Ints, but IIRC "(x:Int, y:Int)" won't type-check to "(a:Int,
> b:Int)".
>
> On Jan 7, 2017, at 23:37, Derrick Ho  wrote:
>
>
> I think pattern matching is the most compelling reason to keep tuples.
>
>
> If they were gone, how would we replace the following?
>
>
> switch (a, b) {
>
> case (value1, value2):
>
> case (value3, value4):
>
> }
>
>
>
> I really have to ask.  What do you use this for?  In general iPhone
> application programming I have never wanted or needed to do that.  I do
> some AudioUnits as well.  Still never needed it.
>
>
> "Need" is a strong word... Yeah, I *could* switch over the first value
> and then for *every single case* nest another switch over the second
> value, but that'd be annoying *and* obscure the underlying logic.
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Derrick Ho via swift-evolution]

Correct me if I am wrong but currently there are only two ways to extract
the value of an associated type.

// 1
switch n {
case foo(let value):
print(value)
}

// 2
if case foo(let value) = n {
print(value)
}

I think it would be nice to have another way. Maybe a tuple-like pattern.

let value = n.foo.0 // returns value as an optional.

If this can already be done, ignore me.


On Sun, Jan 8, 2017 at 2:20 AM Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> I don't think I've ever wanted to distribute the patterns of a switch
> statement across multiple files.  It seems like you want an enum of enums
> if the code you're writing needs this kind of chunking.  Distributing cases
> is also far more brittle than the existing local switch; failing to include
> a file in the build that covers necessary cases now becomes a module-level
> error rather than a statement-local one.  Finally, the proposal seems to do
> the opposite of consolidate and simplify code by introducing quite a lot of
> syntax around what it aims to do, and by muddying the meaning of a keyword
> that was previously only meant for types.
>
> A few conceptual questions:
>
> How does this interact with versioned cases?
> What about enums that carry values?
>
> ~Robert Widmann
>
> 2017/01/06 23:59、Tim Shadel via swift-evolution 
> のメッセージ:
>
> Idea: Consolidate the Code for Each Case in an Enum
>
> ​
>
> # Motivation:
>
> ​
>
> Consolidate all code related to a single enum case in one spot. This makes
> it easier to ensure that all the pieces mesh coherently across that one
> case.
>
> ​
>
> # Background:
>
> ​
>
> Enum cases _feel_ like separately defined, but tightly related structs
> because each case can have distinct associated values. They have special
> privileges that a family of structs doesn't have, like `self = .otherCase`.
> Enums are really awesome.
>
> ​
>
> # Proposed Solution:
>
> ​
>
> Any `func` or dynamic `var` that provides a unique response per `case`
> uses a `switch` to do so. I propose to hide that standard `switch` behind
> some syntactic sugar. Possibly `extension MyEnum.myCase`, assuming that
> nothing extra is allowed there (protocol conformance, generic constraints,
> etc.).
>
> ​
>
> Here's a typical example of a (simplified) enum that represents 2 states,
> and conforms to 2 protocols, each requiring different dynamic values based
> on the case of the enum. In both places, an outer `switch` is used to
> select the current enum case, and the logic within each branch further
> determines the value returned.
>
> ​
>
> ```
>
> protocol State {
>
> mutating func react(to event: Event)
>
> }
>
> ​
>
> enum TokenState: State, CustomStringConvertible {
>
> ​
>
> case expired(at: Date)
>
> case validated(token: String)
>
> ​
>
> var description: String {
>
>   switch self {
>
> case let .expired(at):
>
> return "Expired at \(at)"
>
> case let .validated(token):
>
> return "Token \(token) has been validated."
>
>   }
>
> }
>
> ​
>
> mutating func react(to event: Event) {
>
> switch self {
>
> case .expired:
>
> switch event {
>
> case _ as TokenRefreshed:
>
> self = .validated(token: event.token)
>
> default:
>
> break
>
> }
>
> case .validated:
>
> switch event {
>
> case _ as TokenRejected:
>
> self = .expired(at: Date())
>
> case _ as UserLoggedOut:
>
> self = .expired(at: Date())
>
> default:
>
> break
>
> }
>
> }
>
> }
>
>
>
> }
>
> ```
>
> ​
>
> If we instead allow all the code for each enum case to be consolidated,
> this new code looks much more like the rest of the code we write in Swift.
> Real world enums frequently have many more cases, and as the number of enum
> cases grows consolidating all their logic is increasingly helpful. The
> following proposal is identical to the code above, it simply "hides" the
> outer switch statement of each value.
>
> ​
>
> ```
>
> enum TokenState: State, CustomStringConvertible {
>
> case expired(at: Date)
>
> case validated(token: String)
>
> }
>
> ​
>
> extension TokenState.expired {
>
> ​
>
> var description: String {
>
>   return "Token expired at \(self.at)"
>
> }
>
>
>
> mutating func react(to event: Event) {
>
> switch event {
>
> case _ as TokenRefreshed:
>
> self = .untested(token: event.token)
>
> default:
>
> break
>
> }
>
> }
>
> ​
>
> }
>
> ​
>
> extension TokenState.validated {
>
>
>
> var description: String {
>
>   return "Token \(self.token) has been validated."
>
> }
>
>
>
> mutating func react(to event: Event) {
>
> switch event {
>
> case _ as TokenRejected:
>
> self = .expired(at: Date())
>
> case _ as UserLogged

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Derrick Ho via swift-evolution]

I think pattern matching is the most compelling reason to keep tuples.

If they were gone, how would we replace the following?

switch (a, b) {
case (value1, value2):
case (value3, value4):
}
On Sun, Jan 8, 2017 at 2:31 AM Derrick Ho  wrote:

> Don't remove tuples.
> They make it very convenient to pass multiple values around.
>
> Tuples use .0 instead of [0] which prevents any index out of bounds issues
> at compile time rather than at run time.
>
> Tuples should not adopt a dictionary style access because dictionaries
> imply nil for any key that doesn't exist in the dictionary. Tuples syntax
> prevents you from using non-existent keys.
>
>
> On Sun, Jan 8, 2017 at 1:51 AM David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> > On Jan 7, 2017, at 19:34, Freak Show  wrote:
> >
> > I think you're missing the forrest for the trees here.'
> >
> > Let me ask this:  if you remove tuples from the language - what have you
> lost - really?  You can still say everything you could before.
>
> A really convenient way to pass around multiple values without having to
> bother with a formal struct.
>
> - Dave Sweeris
> ___
> 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] Eliminate tuples - unify member access syntax

[Derrick Ho via swift-evolution]

Don't remove tuples.
They make it very convenient to pass multiple values around.

Tuples use .0 instead of [0] which prevents any index out of bounds issues
at compile time rather than at run time.

Tuples should not adopt a dictionary style access because dictionaries
imply nil for any key that doesn't exist in the dictionary. Tuples syntax
prevents you from using non-existent keys.


On Sun, Jan 8, 2017 at 1:51 AM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > On Jan 7, 2017, at 19:34, Freak Show  wrote:
> >
> > I think you're missing the forrest for the trees here.'
> >
> > Let me ask this:  if you remove tuples from the language - what have you
> lost - really?  You can still say everything you could before.
>
> A really convenient way to pass around multiple values without having to
> bother with a formal struct.
>
> - Dave Sweeris
> ___
> 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] Rename fatalError() API

[Derrick Ho via swift-evolution]

+1️⃣ for unsafecompilable
On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> -Ben
>
> Sent from my iPhone.
>
> > On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I wouldn’t be horribly opposed to adding a function called
> “willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other
> equally explicit name, simply because that way it’d be easy to ensure that
> all such code was revisited before shipping the product.
>
> Come on, it's swift, it'd have to be named something like,
> "UnsafeCompilable".  :)
> ___
> 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] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

Interesting I knew @objc(name) could rename method names; didn't realize
they could be used on enums.
On Thu, Jan 5, 2017 at 6:58 PM Derrick Ho  wrote:

> I updated the proposal
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/master/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> And I also posted the question on Reddit.
>
>
> https://www.reddit.com/r/ObjectiveC/comments/5livbi/improve_ns_string_enum/?st=IXJK9UXL&sh=80e8c7d8
>
>
>
> On Wed, Jan 4, 2017 at 2:51 PM Derrick Ho  wrote:
>
> The underline can be omitted. To remain more consistent.
>
> enum City: String {
> case NewYork = "New York"
> }
>
> typedef NSString * City;
> static City const CityNewYork = @"New York";
>
>
>
> On Wed, Jan 4, 2017 at 2:22 PM Rod Brown  wrote:
>
> I'm not part of the core team, of course, but I like this change in
> principle.
>
> My one concern in this case would be choosing a naming convention for the
> back port that makes sense both ways. The naming convention you propose (
> EnumName_EnumCase) seems inconsistent with the current import of strings
> from Obj-C to Swift. Could we find a way to unify them?
>
> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string interoperable with Objective-C?
>
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other
> way around.
>
> I feel that if you can go one direction you should be able to go back.
>
> @objc
> enum City: String {
> case NewYork = "New York"
> }
>
> Make this available as a global string in objective -c ?
> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>
> I think enum strings should gain better interoperability with swift.
> Something like this:
>
>
>
> enum City: String {
>
> case NewYork = "New York"
>
> }
>
>
>
> This can be ported over to Objective-c like this:
>
>
>
> typedef NSString * City;
>
> static City const City_NewYork = @"New York";
>
>
>
>
> ___
> 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] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

I updated the proposal

https://github.com/wh1pch81n/swift-evolution/blob/master/proposals/-Swift-enum-strings-ported-to-Objective-c.md

And I also posted the question on Reddit.

https://www.reddit.com/r/ObjectiveC/comments/5livbi/improve_ns_string_enum/?st=IXJK9UXL&sh=80e8c7d8



On Wed, Jan 4, 2017 at 2:51 PM Derrick Ho  wrote:

The underline can be omitted. To remain more consistent.

enum City: String {
case NewYork = "New York"
}

typedef NSString * City;
static City const CityNewYork = @"New York";



On Wed, Jan 4, 2017 at 2:22 PM Rod Brown  wrote:

I'm not part of the core team, of course, but I like this change in
principle.

My one concern in this case would be choosing a naming convention for the
back port that makes sense both ways. The naming convention you propose (
EnumName_EnumCase) seems inconsistent with the current import of strings
from Obj-C to Swift. Could we find a way to unify them?

On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
swift-evolution@swift.org> wrote:

I'm trying to revive an old thread. I'd like to hear from the community.

Can we make a swift enum string interoperable with Objective-C?

Currently NS_STRING_ENUM ports from objective-c to swift but not the other
way around.

I feel that if you can go one direction you should be able to go back.

@objc
enum City: String {
case NewYork = "New York"
}

Make this available as a global string in objective -c ?
On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:

I think enum strings should gain better interoperability with swift.
Something like this:



enum City: String {

case NewYork = "New York"

}



This can be ported over to Objective-c like this:



typedef NSString * City;

static City const City_NewYork = @"New York";




___
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] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Derrick Ho via swift-evolution]

So could we add a @trailing or @nontrailing to the block argument to toggle
on and off the feature?


On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Check out this thread
> –it’s
> very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to
> this as well as the ability to use multiple trailing closures like so:
>
> animate(identifier: “”, duration: 0, update: {
> // update
> }, completion: {
> // completion
> }
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> When you have a function with a closure and then another optional default =
> nil closure at the end, like this:
>
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
>
> You can’t use trailing closure syntax for the update argument when
> leaving the completion argument out/default.
>
> This kind of breaks one of the benefits of default arguments, which is
> that you can add them to existing released functions without breaking the
> calling code. This means you have to add a separate convenience function
> without the extra argument, which is annoying and inelegant.
>
> Why not simply add the "completion" parameter before the trailing closure?
> That would still allow existing callers to work, without having to change
> the language.
>
> Another annoying thing is that you can easily miss this error if you
> happen to not use trailing closure syntax in your tests or other usage,
> because adding the extra default argument compiles fine for code that uses
> normal syntax.
>
> The Swift compiler warns when a parameter written as a closure type isn't
> the last parameter. The warning is actually disabled in the specific case
> above because you've written it using a typealias... maybe we should warn
> on such cases (it's worth a bug report). Regardless, in the majority of
> instances, you'll get a warning, so it won't be silent on disabling
> trailing closure syntax.
>
> Are there any issues/gotchas if the trailing closure syntax were to work
> for the last *specified* argument rather than the last *defined* argument?
>
> The main gotcha, and the reason the rule is the way it is, is that it
> means you'd lose trailing closure syntax if the caller wanted to specify an
> argument for the last parameter.
>
>- Doug
>
>
> ​
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

The underline can be omitted. To remain more consistent.

enum City: String {
case NewYork = "New York"
}

typedef NSString * City;
static City const CityNewYork = @"New York";



On Wed, Jan 4, 2017 at 2:22 PM Rod Brown  wrote:

> I'm not part of the core team, of course, but I like this change in
> principle.
>
> My one concern in this case would be choosing a naming convention for the
> back port that makes sense both ways. The naming convention you propose (
> EnumName_EnumCase) seems inconsistent with the current import of strings
> from Obj-C to Swift. Could we find a way to unify them?
>
> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string interoperable with Objective-C?
>
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other
> way around.
>
> I feel that if you can go one direction you should be able to go back.
>
> @objc
> enum City: String {
> case NewYork = "New York"
> }
>
> Make this available as a global string in objective -c ?
> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>
> I think enum strings should gain better interoperability with swift.
> Something like this: enum City: String { case NewYork = "New York" }
> This can be ported over to Objective-c like this: typedef NSString * City;
> static City const City_NewYork = @"New York";
>
> ___
> 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] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

John McCall +1
I agree. The placement should remain the same.
On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Wed Dec 28 2016, Chris Lattner  > wrote:
>
> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>
> it would be ambiguous to move the ‘throws’ keyword to the end of the
> function type, because you'd get:
>
>
> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>
>
> I see.
>
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
>
>  let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.
>
>
> Indeed this is horrid for an ivory tower language designer, but the
> pragmatic among them often have to make concessions to the real world.
> That said, I think this would be worse for typical swift programmers
> as well: it introduces multiple ways to do things,
>
>
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.
>
>
> Chris's point is that we can't stop allowing "throws" where it currently
> is, and
> therefore any proposal which allows it in a new place creates two ways of
> spelling the same thing.
>
> Also, your proposal reinterprets the currently-valid syntax:
>   (_ a : Int) -> (_ b : Float) throws -> Double
> Currently this means a non-throwing function that returns a throwing
> function.
> Your proposal flips it around.
>
> Also, I would find this extremely surprising as a user.  A core aspect of
> the
> first function type is written *inside* the second?  With all respect,
> Dave,
> that is just bizarre. :)
>
> I'm sorry if people dislike the placement of "throws", but that ship has
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems
> for
> negligible benefit.
>
> As I see it, the current syntax has one mild deficiency, called out
> previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or
> returns an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.
>
> For what it's worth, this visual ambiguity is precisely why I would insist
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>
> John.
>
>
>
> which work inconsistently and surprisingly in some cases.
>
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?
>
>
> Not really, no.
>
> --
> -Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Switch statement tuple labels

[Derrick Ho via swift-evolution]

In your first example the switch statement is evaluating whether the given
tuple of type (_:bool, _:bool) matches another tuple of type (_: bool, y:
bool)

The type signature doesn't match.

I believe the change would not be additive like you say because it seems
like it would require a change in how tuple compare with each other.


On Mon, Jan 2, 2017 at 12:00 AM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, it turns out, I was testing it on already established values. The
> first of the following two examples works but the second does not.
>
> switch (true, y: false) {
> case (true, y: false): print("tf")
> default: print("nope")
> }
>
> let testTuple2 = (true, false)
>
> switch testTuple2 {
> // error: tuple pattern element label 'y' must be '_'
> case (true, y: false): print("tf")
> default: print("nope")
> }
>
> I think this gets a 95% Emily Litella (
> https://en.wikipedia.org/wiki/Emily_Litella). "Nevermind."
>
> And thanks, Tony,
>
> -- E
>
>
> On Jan 1, 2017, at 8:49 PM, Tony Allevato  wrote:
>
> The "after" example you posted seems to work already in Swift today. Is
> there something I'm missing?
>
>
> On Sun, Jan 1, 2017 at 7:35 PM David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPhone
>
> On Jan 1, 2017, at 19:25, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Was helping a friend with some code and got inspired. I decided to throw
> this on list to see if there's any traction.
>
> *Idea*: Introduce optional argument labels to tuples in switch statements
>
> *Motivation*: Cases can be less readable when pattern matching tuples.
> Semantically sugared, optional argument labels could increase readability
> for complex `switch` statements by incorporating roles into cases.
>
> Here's an example before:
>
> fileprivate func chargeState(for battery: BatteryService)
> -> ChargeState
> {
> switch (battery.state, battery.isCalculating) {
> case (.isACPowered, true):
> return .calculating(isDischarging: false)
> case (.isACPowered, _) where battery.isCharging:
> return .charging
> case (.isACPowered, _):
> return .acPower
> case (_, true):
> return .calculating(isDischarging: true)
> default:
> return .batteryPower
> }
> }
>
>
> and after:
>
> fileprivate func chargeState(for battery: BatteryService)
> -> ChargeState
> {
> switch (battery.state, *calculating: battery.isCalculating*) {
> case (.isACPowered, *calculating: true*):
> return .calculating(isDischarging: false)
> case (.isACPowered, _) where battery.isCharging:
> return .charging
> case (.isACPowered, _):
> return .acPower
> case (_, *calculating: true*):
> return .calculating(isDischarging: true)
> default:
> return .batteryPower
> }
> }
>
>
> It's a pretty minor change, and I could see it being added to allow case
> statements to be more readable with a minimal change to the compiler. I
> also have a back-burnered proposal I intend to introduce in Phase 2 that
> would introduce Boolean raw value enumerations for flags.
>
> Thoughts?
>
>
> I can't think of a reason not to do that... +1
>
> - Dave Sweeris
> ___
> 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] [Proposal] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

Anyone on the core team like to say anything?
On Fri, Dec 30, 2016 at 9:15 AM Derrick Ho  wrote:

> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string interoperable with Objective-C?
>
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other
> way around.
>
> I feel that if you can go one direction you should be able to go back.
>
> @objc
> enum City: String {
> case NewYork = "New York"
> }
>
> Make this available as a global string in objective -c ?
> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>
> I think enum strings should gain better interoperability with swift.
> Something like this: enum City: String { case NewYork = "New York" }
> This can be ported over to Objective-c like this: typedef NSString * City;
> static City const City_NewYork = @"New York";
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

I'm trying to revive an old thread. I'd like to hear from the community.

Can we make a swift enum string interoperable with Objective-C?

Currently NS_STRING_ENUM ports from objective-c to swift but not the other
way around.

I feel that if you can go one direction you should be able to go back.

@objc
enum City: String {
case NewYork = "New York"
}

Make this available as a global string in objective -c ?
On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:

> I think enum strings should gain better interoperability with swift.
> Something like this: enum City: String { case NewYork = "New York" }
> This can be ported over to Objective-c like this: typedef NSString * City;
> static City const City_NewYork = @"New York";
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace named returns with `out` parameters?

[Derrick Ho via swift-evolution]

-1

On Wed, Dec 28, 2016 at 9:37 AM Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> –1. I'm not sure there's a reason to draw a line from
> removal-of-tuple-splat to removal-of-tuple-returns, other than the idea
> that they both involve tuples. In a lot of languages, purely-"out"
> parameters are a workaround for the fact that the language wasn't designed
> to allow functions to return multiple values easily. Since Swift does allow
> this, eliminating and adding "out" params is a step *backward*, not a step
> forward.
>
> "Inout" parameters at least serve an important role with respect to
> in-place mutability. "Out"-only parameters don't seem like something that
> would have much value in Swift.
>
> The syntactic distinction between inputs and outputs in Swift's function
> syntax is important to readability—I find the example given with "out"
> params to be considerably harder to parse mentally than the version that
> returns a tuple. From the point of view of making the language easy for
> newcomers to learn... replacing tuple returns with "out" parameters would
> be extremely harmful.
>
>
> On Wed, Dec 28, 2016 at 3:10 AM Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Some people on the list wondered, why we have moved from tuples in
> function parameters, but multiple returns are still implemented using
> tuples? The following code still compiles:
>
> func position() -> (x: Int, y: Int) {
> return (x: 0, y: 0)
> }
> let (y, x) = position()
>
> (Maybe it’s a bad example, because naturally we’d use Point struct. Let’s
> pretend those two parameters don’t make sense as a struct.)
>
> What I want to discuss is if we should introduce out parameters *and*
> make them the default for multiple returns for Swift 4. The syntax would
> look like:
>
> func position(x: out Int, y: out Int) {
> x = 0
> y = 0
> }
> var y
> position(x: let x, y: y)
>
> out arguments can be any patterns allowed on the left side of assignment,
> including wildcard pattern and tuple destructuring pattern.
> ​
> ___
> 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] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

Right. it should support the normal return type as well as the errors. Here
is my revised suggestion.

func foo() throws -> String {}

switch try foo() {
case .returnValue(let value):
// do something with value

case .MyEnumErrorFirstError:
// handle error

default:
// handle NSError
}
On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu  wrote:

> On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suppose "throws" could be enhanced to produce a compiletime enum
>
> func bar() throws {
> throw NSError()
> throw MyEnumError.firstError
> }
>
> Under the hood each expression passed to "throw" could make something like
>
> enum bar_abcdefj_throw {
> case genericError // all NSError go here
> case MyEnumErrorFirstError
> }
>
> Where abcdefj is unique characters.
>
>
> This enum would only be visible through the catch blocks which would act
> like a switch statement.
>
> Speaking of switch statements do they currently support "try" expressions?
>
> switch try foo() {
> case .MyEnumErrorFirstError:
> // handle error
> default:
> // handle NSError and everything else
> }
>
>
> If I'm not mistaken, `switch try foo()` switches over the return value of
> foo(); you'd switch over the error in a catch block.
>
>
> The benefit of this approach is that it would be additive. And no source
> breakage.
>
> At the risk of being off topic if there is interest in this I can start a
> new thread for this.
>
> On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
> wrote:
>
> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw;
> currently to know that you need to consult documentation which, while fine,
> isn't the best way to do that when the compiler could know and it's then up
> to you whether to let it auto-complete for all throwable types, or just be
> generic for some or all of them (or pass the buck).
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened, i.e- an
> illegal argument type error shouldn't occur if you're using a method
> correctly, so it's more like something you might check as an assertion. I
> should have been more clear that the main difference is in how fix-its
> might recommend the errors are handled; specific types would produce catch
> blocks, but optionals might be grouped into a catch-all at the end (e.g-
> they're special interest that you might not be bothered about), but the
> compiler would still be aware of them should you decide to add them.
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> One thing to note with explicit errors is that we'd basically introduce
> sum types…
>
>
> Not necessarily; you could think of explicit errors as being doing
> something like:
>
> enum MyErrorType {
> case io_error(IOError)
> case illegal_argument(IllegalArgumentError)
> case unknown(Error)
> }
>
> i.e- boilerplate we could do right now, but would prefer not to, but still
> allowing it to be handled as an enum.
>
>
> ___
> 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] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

I suppose "throws" could be enhanced to produce a compiletime enum

func bar() throws {
throw NSError()
throw MyEnumError.firstError
}

Under the hood each expression passed to "throw" could make something like

enum bar_abcdefj_throw {
case genericError // all NSError go here
case MyEnumErrorFirstError
}

Where abcdefj is unique characters.


This enum would only be visible through the catch blocks which would act
like a switch statement.

Speaking of switch statements do they currently support "try" expressions?

switch try foo() {
case .MyEnumErrorFirstError:
// handle error
default:
// handle NSError and everything else
}

The benefit of this approach is that it would be additive. And no source
breakage.

At the risk of being off topic if there is interest in this I can start a
new thread for this.
On Tue, Dec 27, 2016 at 9:54 AM Haravikk 
wrote:

> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote:
> Imho this is no problem:
> Right now, we basically have "throws Error", and no matter what is
> actually thrown, we can always catch exhaustive by keeping the statement
> unspecific.
>
>
> True, but for me it's more about knowing what a method can throw;
> currently to know that you need to consult documentation which, while fine,
> isn't the best way to do that when the compiler could know and it's then up
> to you whether to let it auto-complete for all throwable types, or just be
> generic for some or all of them (or pass the buck).
>
> myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }
>
> Imho to much confusion with no real benefit:
> Shouldn't it be up to the caller to decide which errors need special
> treatment? The library can't enforce proper handling at all.
>
>
> Partly, but it's really just intended to distinguish things that are
> genuine runtime errors, versus things that shouldn't have happened, i.e- an
> illegal argument type error shouldn't occur if you're using a method
> correctly, so it's more like something you might check as an assertion. I
> should have been more clear that the main difference is in how fix-its
> might recommend the errors are handled; specific types would produce catch
> blocks, but optionals might be grouped into a catch-all at the end (e.g-
> they're special interest that you might not be bothered about), but the
> compiler would still be aware of them should you decide to add them.
>
> If the distinctions not significant enough though then the "optional"
> error types could just be ignored for now, I think the more important
> ability is the ellipsis indicating "plus other errors" so we can specify
> either exhaustive lists of error types, or keep them open-ended, in which
> case the types listed are those that would be placed as catch blocks, with
> the ellipsis indicating that a catch-all is still required (or throw on the
> current method).
>
> One thing to note with explicit errors is that we'd basically introduce
> sum types…
>
>
> Not necessarily; you could think of explicit errors as being doing
> something like:
>
> enum MyErrorType {
> case io_error(IOError)
> case illegal_argument(IllegalArgumentError)
> case unknown(Error)
> }
>
> i.e- boilerplate we could do right now, but would prefer not to, but still
> allowing it to be handled as an enum.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

Daniel Leping, I am unfamiliar with java. Do you have any resources that
describe the nightmare in detail?
On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote:

> -1 for specifying errors for throws. Please don't. Proven by practice in
> java it's a nightmare.
>
> In Java, this topic is really interesting:
> It sounds like a great idea, but in real-life situations, afaics everyone
> hates checked exceptions.
>
> But Swift isn't Java, and our error handling is different from most
> established languages, so imho we shouldn't base that decision on
> experiences from other models only:
> I don't see downsides, because you already need "try" for everything that
> can throw, and afaics, it would be easy to ignore the information that only
> a set of exceptions can happen in a given context.
>
> So, imho before there is a decision wether "throws" should be moved, the
> possibility to annotate it with a fixed set of error types should be either
> abandoned or incorporated.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

I like the idea of "throw" having information about what might be thrown.

Maybe you have an enum of errors that may be thrown. How would the
programmer know what might get thrown if they don't know the implementation
details?

While adding the throwing info in the comments is good, we might be better
off adding an attribute

@throws(Error_Enum, Specific_error, ...)

Where the stuff in parenthesis is a comma separated list of possible
errors. Maybe it's all the cases in enum are possible or maybe only a
specific few are used...

Then we can do something like this

@throws(MyErrorEnum)
func foo() {

throw MyErrorEnum.firstError

}

With this info we can properly catch all error cases

do {
try foo()
} catch MyErrorEnum.firstError {

} catch {
}

As for blocks that throw we could probably add it in the same place where
@escaping is.
On Mon, Dec 26, 2016 at 11:20 PM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> Maybe we can let the compiler use documentation comments for
> type-checking. Currently you can do:
>
> /// does something
> ///
> /// - returns: Something cool
> ///
> /// - throws:
> ///- `MyError.Something` if a certain thing happens
> ///- `POSIXError` if something goes horribly wrong
> ///
> func doSomething() throws -> Int
>
> I would prefer if we found some way to integrate that stuff in to the
> compiler. I mean, you would probably want to document why the errors get
> thrown anyway, and it’s better than clobbering up the function signature.
>
> Maybe it seems weird to have the compiler look inside comments (especially
> if the set of thrown errors becomes a resilience-breaking part of the
> function), but why not? Swift’s documentation comments are just another
> source of structured data, and the compiler already understands them at a
> superficial level.
>
> Just saying, there are options.
>
> On 27 Dec 2016, at 07:55, Tony Allevato  wrote:
>
> One thing to keep in mind is that, if I recall correctly, some members of
> the core team have expressed a desire to enhance `throws` by letting users
> list the specific error types that a function can throw. If that is
> something that might happen in the future, moving the `throws/throwing` to
> the front would add a significant amount of noise before the function name.
>
>
> On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that this could do with revision. It looks particularly ugly when
> you’re dealing with throwing closures.
>
> Recently I had a signature like:
>
> public func scan(length: File.ByteOffset.Stride?,
>  by frameSize: File.ByteOffset.Stride,
>  with handler:
> (_ range: Range, _ data: UnsafeRawBufferPointer) throws -> 
> Bool) throws -> File.ByteOffset.Stride
>
> It can get difficult to parse the signature towards the end. Marking the
> handler and function as throwing closer to the beginning would make it more
> readable IMO. One thing it allows me to do more easily is to remove the
> spaces around the arrow for the closure parameter (just a little thing
> which I find helps me read the trailing closure/return type more quickly).
>
> public throwing func scan(length: File.ByteOffset.Stride?,
>  by
> frameSize: File.ByteOffset.Stride,
>  with handler: throwing
> (_ range: Range, _ data: UnsafeRawBufferPointer)->Bool)
> -> File.ByteOffset.Stride
>
> - Karl
>
> On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swifters,
>
> I've been writing a lot more Swift code recently, and I have found that
> the default placement of the 'throws' declaration is often confusing,
> especially to those of us switching from languages where the type of errors
> thrown is explicitly defined (like Java)
>
> For example,
>
> // This is pretty clear, this can throw an error
> func foo() throws
> { ... }
>
> // Also pretty clear, this returns a String
> func bar() -> String
> { ... }
>
> // Confusing. Does this throw a String? Does it return a String? Does it do 
> both?
> // I personally keep reading this as 'this can throw a String'
> func baz() throws -> String
>
> // Equivalent code in Java (not a model, just for clarification of why the 
> above is confusing)
> String baz() throws StringFormatException
>
> I therefore suggest either tweaking the syntax around, or moving, the
> `throws` keyword to avoid this confusion.
>
> Some ideas I've had:
>
> // Add a comma to separate them
> func baz() throws, -> String
>
> // Move `throws` to the end
> func baz() -> String throws
>
> // Change it to a prefix modifier (like `mutating`)
> throwing func baz() -> String
>
> I'm still not sold on any of the above syntaxes, but I would love to hear
> your feedback.
>
> This would affect existing code, but it would be a fairly small change
> that would result in very large readability improvements, espec

Re: [swift-evolution] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

I like to imagine "throws -> returnType" like a special tuple

let t = (e: NSError?, r: returnType)

Where "try" is a special function that accepts a tuple argument; a success
closure; and one or more error blocks

func try(
_ t: (e: NSError?, r: returnType)
, do: ()->()
, catch: ((Error)->())...
)

So you could think of it as modifying the return type.
On Mon, Dec 26, 2016 at 8:19 PM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> IMO, considering "throws" is a modifier of function/method and determines
> how the function can be called (another good example is mutating) the
> logical approach would be to make things consistent and move everything
> either to the beginning or to the end of declaration.
>
> As long as "throws" is the only modifier at the end it's very logical to
> move it to the beginning and rename to "throwing". It feels like "throws"
> at the end is rather a legacy, probably from other languages and was a
> _default_ way of thinking at the time of initial implementation.
>
> I personally can live with both, though for the sake of consistency it
> should be moved to the beginning.
>
> On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As far as I know, `throws` only affects whether or not the code must be
> marked with a `try` statement, the actual return type/value is unchanged
> (since it would be unreached if an error was thrown).
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
>
>
> On Dec 26, 2016, at 1:18 PM, David Sweeris  wrote:
>
>
> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swifters,
>
> I've been writing a lot more Swift code recently, and I have found that
> the default placement of the 'throws' declaration is often confusing,
> especially to those of us switching from languages where the type of errors
> thrown is explicitly defined (like Java)
>
> For example,
>
> // This is pretty clear, this can throw an error
>
> func foo() throws
>
> { ... }
>
>
>
> // Also pretty clear, this returns a String
>
> func bar() -> String
>
> { ... }
>
>
>
> // Confusing. Does this throw a String? Does it return a String? Does it do 
> both?
>
> // I personally keep reading this as 'this can throw a String'
>
> func baz() throws -> String
>
>
>
> // Equivalent code in Java (not a model, just for clarification of why the 
> above is confusing)
>
> String baz() throws StringFormatException
>
> I therefore suggest either tweaking the syntax around, or moving, the
> `throws` keyword to avoid this confusion.
>
> Some ideas I've had:
>
> // Add a comma to separate them
>
> func baz() throws, -> String
>
>
>
> // Move `throws` to the end
>
> func baz() -> String throws
>
>
>
> // Change it to a prefix modifier (like `mutating`)
>
> throwing func baz() -> String
>
> I'm still not sold on any of the above syntaxes, but I would love to hear
> your feedback.
>
> This would affect existing code, but it would be a fairly small change
> that would result in very large readability improvements, especially for
> newcomers, and *especially* for those coming for a language such as Java.
>
> -thislooksfun (tlf)
>
>
> Does `throws` affect the actual return type? That is, is the size of the
> returned data different between "func foo() -> Int8" and "func foo() throws
> -> Int8"? If so, the "throws" is quite literally part of the return type
> and the current syntax reflects that. If not, I *think* I'd probably be
> in favor of that last "prefix modifier" suggestion with either "throwing"
> or "@throwing" (depending on the exact semantics of the "@" part — I'm a
> bit unclear on that detail)... probably... maybe... I'll have to think
> about it some more.
>
> - Dave Sweeris
>
>
> ___
>
> 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] [SwiftPM] Proposal: Add support for test-only dependencies

[Derrick Ho via swift-evolution]

We need this.
On Mon, Dec 26, 2016 at 11:57 AM thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

> (I think this is the right place for this suggestion, but please let me
> know if I'm mistaken)
>
> There is currently no supported way to have some dependencies only used
> for testing (`swift test`), and the workarounds for it, while workable, are
> unnecessary crude.
>
> Currently, what a lot of projects are doing is defining a
> `.Package.test.swift` file that is then copied over `Package.swift` when
> tests are to be run (on external CI, for example). While this works, it
> adds a extra step and another point of failure (if you forget to add a new
> dependency to both `Package` files, for example.
>
> What I propose is a new section of `Package.swift`, labelled either
> `testDependencies` or `devDependencies`, and the modules referenced within
> are only loaded/compiled when running `swift test`
>
> // Package.swift
> import PackageDescription
> let package = Package(
> name: "Project",
> targets: [
>   Target(name: "BoxioDebug", dependencies: ["Core"]),
> ],
> dependencies: [   //Same as before
> ],
> testDependencies: [
> .Package(url: 
> "https://github.com/FooBar/PackageOnlyNeededForTesting.git";, majorVersion: 1),
> ]
> )
>
>
> This solves having to manually switch out Package files or `.Package`
> statements inside one Package file when trying to run tests, and keeps all
> dependencies neatly organized in one file.
>
> This change is purely additive and optional, no existing code needs to
> change for this to be added.
>
> A real world example is a dependency on Quick (or another such testing
> framework), that itself uses XCTest, and thus crashes when being run
> outside of `swift test` (add Quick to Package.swift, run `swift build` and
> run the compiled binary). With the new `test[dev]Dependencies`, running
> `swift build` wouldn't even see Quick, and thus would compile and run
> correctly, but `swift test` would both see and use Quick for running the
> test suite.
>
>
> *Other solutions considered:*
> Another potential solution is to only compile the dependencies that were
> actually used when running `swift build`, since that seems to be the cause
> of the above problem.
>
>
> -thislooksfun (tlf)
>
> ___
> 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] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

I personally do not see anything wrong with its current placement.

It may be there because it was based on an existing cocoa pattern from
objective-c

- (NSString *)bazWithError:(NSError **)error { ... }

Because objective c could only return one thing, using pointer-to-pointer
was needed to deliver more than one.

When swift came along it became this...

func baz(error: NSErrorPointer) -> String

The style felt old-fashioned and was replaced with throw.

func baz() throws -> String


The evolution is consistent.  The pattern is familiar.  I think we should
keep the placement of throw as it is.

On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution <
swift-evolution@swift.org> wrote:

Hello Swifters,

I've been writing a lot more Swift code recently, and I have found that the
default placement of the 'throws' declaration is often confusing,
especially to those of us switching from languages where the type of errors
thrown is explicitly defined (like Java)

For example,

// This is pretty clear, this can throw an error

func foo() throws

{ ... }



// Also pretty clear, this returns a String

func bar() -> String

{ ... }



// Confusing. Does this throw a String? Does it return a String? Does
it do both?

// I personally keep reading this as 'this can throw a String'

func baz() throws -> String



// Equivalent code in Java (not a model, just for clarification of why
the above is confusing)

String baz() throws StringFormatException

I therefore suggest either tweaking the syntax around, or moving, the
`throws` keyword to avoid this confusion.

Some ideas I've had:

// Add a comma to separate them

func baz() throws, -> String



// Move `throws` to the end

func baz() -> String throws



// Change it to a prefix modifier (like `mutating`)

throwing func baz() -> String

I'm still not sold on any of the above syntaxes, but I would love to hear
your feedback.

This would affect existing code, but it would be a fairly small change that
would result in very large readability improvements, especially for
newcomers, and *especially* for those coming for a language such as Java.

-thislooksfun (tlf)







___


swift-evolution mailing list


swift-evolution@swift.org


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

Re: [swift-evolution] Switch statement using blocks for conditions

[Derrick Ho via swift-evolution]

Can you not write this?

switch condition {
case 1: do {
//
}

case 2: do {
//
}
}
On Fri, Dec 23, 2016 at 8:35 AM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Marco,
>
> This idea has already been discussed on this list; however,
> source-breaking changes require "extreme" justification and this particular
> idea has not been found to provide obvious benefit. Moreover, Swift cases
> allow fallthrough, which is less explicable when you surround each case
> with braces.
>
> The focus of this phase of Swift Evolution is listed on the GitHub site
> and is generally clustered around ABI stability and completing generics.
>
> Cheers,
>
> Xiaodi
> On Fri, Dec 23, 2016 at 07:04 Marco Scannadinari via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> I found it odd that the `label:` style is used for switch-case conditions,
> considering that Swift does not have implicit fallthrough. To me the label
> style only makes sense if you think of conditions essentially as labels for
> a goto statement, which implies fallthrough.
>
> Personally I think this syntax would make more sense:
>
> switch condition {
>   case 1 {
> //
>   }
>
>   case 2 {
> //
>   }
> }
>
> This is how Rust implements match, although it is an expression so it
> especially applies to that context. Nonetheless I think the above syntax
> not only looks a lot nicer but makes more sense, especially since the
> current syntax is the only instance where Python-style colons and
> indentation are used for designating sections of code rather than braces.
>
> Thoughts?
>
> -Marco
> ___
> 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] "with" operator a la O'Caml?

[Derrick Ho via swift-evolution]

I believe variables under private(set) can still be accessed with KVC (At
least when the class inherits from nsobject.)
On Thu, Dec 22, 2016 at 9:19 AM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:

> Point taken. I think Swift supports both styles reasonably well. Initially
> it looked like writing the 'with' function would be troublesome but it
> turned out to be quite simple.
>
> I appreciate the point you're making, which is that you get much of the
> value of purely immutable values with Swift's mutable structures + value
> semantics + let constant structs. And, you also get a simpler
> implementation in some cases (e.g. not needing functions like 'with').
>
> Swift has a pretty interesting model here that seems to capture some of
> the best parts of the imperative and immutable/functional styles. For
> example, I had to check whether this worked as expected:
>
> ```
> struct Person {
> var name: String
> var address: String
> }
>
> class C {
> private(set) var currentPerson = Person(name: "Andy", address: "1
> Battery St")
> }
>
> func f() {
> let instance = C()
> instance.currentPerson.name = "Dave"   // Cannot assign to property:
> 'currentPerson' setter is inaccessible
> }
> ```
>
> This means the implementation of class C can set the currentPerson and its
> properties, but the currentPerson is immutable to the outside. A similar
> thing could be accomplished with an immutable Person, but you still need to
> use private(set), so it's no more complicated or risky to use the mutable
> Person.
>
> The difference is mostly one of style, way of thinking, and psychology.
> For some people seeing the declaration of Person having vars is
> uncomfortable if they are used to a functional style. "If I have a Person,
> will it be changed unexpectedly out from under me?" For people who know
> Swift well, the fact that it's a struct means any potential change to
> Person can only happen under controlled circumstances like an inout
> parameter, and only if I declare it a var. This discussion was very helpful
> for me to understand the nuances of struct better.
>
> Thanks,
>
> Andy
>
> On Dec 22, 2016, at 7:01 AM, Matthew Johnson 
> wrote:
>
> Yes, this is true.  However, this thread is about improving the
> convenience of immutable structs / functional code.  It is quite common in
> such code that the previous value is no longer needed.  I am encouraging
> people to focus on what the real benefits of this style is (value
> semantics) and how the same benefit might be achieved in a different way in
> a hybrid language like Swift.
>
>
> ___
> 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] "with" operator a la O'Caml?

[Derrick Ho via swift-evolution]

Jeremy,

The problem you present is not a mutability problem but rather a cache
design problem. If your hash value truly is expensive then you only want to
calculated it when you need to...

struct Person: Hashable
{
var firstName: String {didSet { _hashValue = nil }}
var lastName: String {didSet { _hashValue = nil }}
private var _hashValue: Int?
var hashValue: Int {
if _hashValue == nil {
_hashValue = firstName ^ lastName // the "expensive hash
calculation"
}
return _hashValue!
}
}

In the above implementation the hash value would only calculate the hash
when firstName or lastName were changed.

However in your example your hash method would calculate a new one every
time you copy a Person, but mine would not.

On Tue, Dec 20, 2016 at 6:44 AM Martin Waitz via swift-evolution <
swift-evolution@swift.org> wrote:

Am 2016-12-19 20:44, schrieb Erica Sadun via swift-evolution:


> https://github.com/apple/swift-evolution/pull/346





-1


I don't like where this is heading.





If you want to introduce method cascading, then have a look at Dart.





E.g. the example from the pull request could be something like this:





 let questionLabel = UILabel()


 ..textAlignment = .Center


 ..font = UIFont(name: "DnealianManuscript", size: 72)


 ..text = questionText





The expression could still work on a mutable struct/class which later


becomes


immutable by using the `let` assignment.





The other example which silently creates a new instance is even worse.


If you want to do something like this, then please do it more


explicitly.


E.g.:





 let fewerFoos = foos.clone()


 ..remove(at: i)





Anyway, all of this is simply syntactic sugar and should wait...





--


Martin


___


swift-evolution mailing list


swift-evolution@swift.org


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

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

[Derrick Ho via swift-evolution]

The core team designed swift blocks to range from concise to verbose. Which
one you use depends on your needs.

If you want to write parenthesis then by all means write parenthesis; no
one is stopping you.

I would rather keep the block syntax as it is so that everyone can choose
the style that matches their needs.

On Mon, Dec 19, 2016 at 1:52 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This issue about `numbers in` was raised during review of SE-0066; if I
> recall, the core team considered and rejected disallowing that syntax in
> closures. Since we're minimizing source-breaking changes, the issue is
> settled in my view, having been proposed, commented upon, reviewed, and
> rejected.
> On Mon, Dec 19, 2016 at 15:39 Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution <
> swift-evolution@swift.org>:
>
>
> var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = {
> numbers -> ([Int], [Int]) in
> var evenNumberArray = [Int]()
> var oddNumberArray = [Int]()
>
> for number in numbers {
> number % 2 == 0 ? evenNumberArray.append(number) :
> oddNumberArray.append(number)
> }
>
> return (evenNumberArray, oddNumberArray)
> }
>
>
>
> The above code is valid, because:
>
>
>
>
>
>1. Multi-return is just a type of tuple with labeled components.
>
>2. Labeled tuples and normal tuples are implicitly convertible.
>
>
>
>
> The only way we could make such code invalid is by removing labeled tuples
> altogether. -1 on that.
> This problem mostly refers to code style, and the above variant can be
> more self-documenting in some cases.
>
>
> Also, again for consistency and clarity, parameters in Closures should
> always be surrounded by parentheses, even single parameters:
>
> var oneParameterAndMultipleReturn: ([Int]) -> ([Int], [Int]) = { (numbers)
> -> (even:[Int], odd:[Int]) in
> var evenNumberArray = [Int]()
> var oddNumberArray = [Int]()
>
> for number in numbers {
> number % 2 == 0 ? evenNumberArray.append(number) :
> oddNumberArray.append(number)
> }
>
> return (evenNumberArray, oddNumberArray)
> }
>
>
>
> This should be considered a bug. numbers in or (numbers) in or (numbers)
> -> (...) in, but not numbers -> (...) in, because the latter forms should
> be correct types.
> Whether or not just numbers in should be allowed, is another talk.
>
>
> ​
>
>
> ___
>
>
> 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] "with" operator a la O'Caml?

[Derrick Ho via swift-evolution]

That is correct Andy. Let-constant can not be assigned a new value after it
gets its initial value.

It is unclear why you are against turning your properties into var's.
Because you are using structs, all properties are copied by value.

struct Person {
  var name: String
}

let andy = Person(name: "Andy")
var brandon = andy; brandon.name = "Brandon"

andy.name // "Andy"
brandon.name // "Brandon"

I believe this accomplishes the same thing you wanted in with(name:)

On Mon, Dec 19, 2016 at 1:26 PM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:

Thanks Erica, I wasn't aware of that Swift evolution proposal. If I'm
reading it right, this wouldn't work with structs with let-variables...?
Here's what I get with this example:

struct Person {
let name: String
let address: String
}

@discardableResult
public func with(_ item: T, update:
(inout T) throws -> Void) rethrows -> T {
var this = item
try update(&this)
return this
}

let john = Person(name: "John", address: "1 battery st")
let jane: Person = with(john) { $0.name = "Jane" } // Test.swift:24:41:
Cannot assign to property: 'name' is a 'let' constant

Andy


On Dec 19, 2016, at 11:44 AM, Erica Sadun  wrote:

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

Be aware that there's a bug that's being worked on:

https://bugs.swift.org/browse/SR-2773

-- E


On Dec 19, 2016, at 12:40 PM, Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:

Of course. Thanks for pointing out the obvious solution. This preserves the
immutability of the struct and doesn't require O(n^2) code for structs with
large numbers of fields.

I was thinking of a generic solution - perhaps something like a synthetic
initializer that does what your solution does. But that may be overkill
given how relatively easy it is to do this per struct...

On the other hand a generic solution would encourage using immutable
structs. I wasted too much time trying to solve this, I suspect others
would just give up and use var, or even classes.

Andy

On Dec 19, 2016, at 10:43 AM, Nick Keets  wrote:











You are probably asking for a generic solution, but for a specific struct
you can implement it like this:




extension Person {
func with(name: String? = nil, address: String? = nil, phone: String? =
nil) -> Person {
let name = name ?? self.name
let address = address ?? self.address
let phone = phone ?? self.phone
return Person(name: name, address: address, phone: phone)
}
}












On 19 Dec 2016, 20:28 +0200, Andy Chou via swift-evolution <
swift-evolution@swift.org>, wrote:


I like that structs are value types in Swift, this encourages the use of
immutable data. O'Caml has an operator "with" that allows for copying an
existing struct with a change to one field. I looked at Lenses for this
functionality and it seems like a lot to digest for something so simple. I
also tried to implement this using a constructor, or a function, and it was
not obvious how to do so without a lot of code duplication.





What's I'm looking for is something like this (not necessarily with this
syntax):





struct Person {


let name: String


let address: String


let phone: String


}





func f() {


let andy = Person(name: "Andy", address: "1 Battery St., San Francisco,
CA", phone: "1234567")


let chris = andy.with(name: "Chris")


let dave = andy.with(address: "50 Townsend St., San Francisco, CA")


}





I tried to implement a "with" function like this but default arguments
cannot reference properties of self. Same problem trying to do this in a
constructor.





Obviously it's possible to create an entirely new Person specifying the
values from an existing Person, but this is very tedious with structures
with many properties.





Anyone taken a look at this before? Any suggestions?





Andy





___


swift-evolution mailing list


swift-evolution@swift.org


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









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



___


swift-evolution mailing list


swift-evolution@swift.org


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

Re: [swift-evolution] "with" operator a la O'Caml?

[Derrick Ho via swift-evolution]

struct Person {
Var name: String = ""

func with(name n: String) -> Person {
var a = self
a.name = name
return a
}
}

let andy = Person().with(name: "Andy")
let brandon = andy.with(name: "Brandon")
On Mon, Dec 19, 2016 at 10:28 AM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:

> I like that structs are value types in Swift, this encourages the use of
> immutable data. O'Caml has an operator "with" that allows for copying an
> existing struct with a change to one field. I looked at Lenses for this
> functionality and it seems like a lot to digest for something so simple. I
> also tried to implement this using a constructor, or a function, and it was
> not obvious how to do so without a lot of code duplication.
>
> What's I'm looking for is something like this (not necessarily with this
> syntax):
>
> struct Person {
> let name: String
> let address: String
> let phone: String
> }
>
> func f() {
> let andy = Person(name: "Andy", address: "1 Battery St., San
> Francisco, CA", phone: "1234567")
> let chris = andy.with(name: "Chris")
> let dave = andy.with(address: "50 Townsend St., San Francisco, CA")
> }
>
> I tried to implement a "with" function like this but default arguments
> cannot reference properties of self. Same problem trying to do this in a
> constructor.
>
> Obviously it's possible to create an entirely new Person specifying the
> values from an existing Person, but this is very tedious with structures
> with many properties.
>
> Anyone taken a look at this before? Any suggestions?
>
> Andy
>
> ___
> 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] URL Literals

[Derrick Ho via swift-evolution]

I suppose if compile time validation is desired I guess we can do something
similar to @ibdesignables. Except instead of live rendering UIViews we
would render the url

Marking a URL like this
@urlvalidation("a URL string")

Would make it fire a compiletime URL request and give a warning if it was a
bad URL but if it is a good URL then it returns a URL instance
On Sat, Dec 17, 2016 at 1:02 PM Callionica (Swift) via swift-evolution <
swift-evolution@swift.org> wrote:

> It would be a good idea for literals of different types to be easily
> recognizable in the source by human readers and extractable from the source
> by tools. I'm sure everyone agrees that it's annoying/risky when you can't
> even distinguish localizable strings (user messages) from non-localizable
> strings. I'm in support of the (separate) concepts of 1) better compile
> time support for URLs and 2) better compile time support for user code
> (literal parsing; constexpr; macros). I hope the solution will consider how
> refactoring tools can extract literal URLs from the source and replace with
> URLs read from a configuration.
>
> I won't risk derailing the thread completely by going in to detail, but
> when I think of better compile-time support for URLs, the features that I
> first think of are:
> 1) A specific subtype for URLs in a protocol family:
> a) Local File URLs
> b) "Web URLs" (specifically HTTP & HTTPS)
> 2) A specific subtype for absolute URLs
>
> Those are library-level concerns, but I mention them so that anyone with a
> general interest in improving compile time support for URLs might have a
> chance of finding them.
>
> -- Callionica
>
>
> On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I like the David Sweeris idea best. The syntax is cleaner and the type URL
> "knows what to do with itself".
>
> let url: URL = "https://example.com";
>
> I have strong reservations about hard-coded URLs as an SDLC 🚂 wreck
> waiting to happen, but the world of mid-day build and deploy might mitigate
> this, except when the developers are laid off and an acquisition or service
> consolidation causes a domain or URL change.  Having seen this many times I
> have always put URLs in a properties file for bootstrapping, and a database
> for post-bootstrap.  This allows per-instance customization and live
> instance changes which is also usually necessary.
> ___
> 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] URL Literals

[Derrick Ho via swift-evolution]

let url = URL(string: "https://example.com";)!

let url = #url("https://example.com";)

Are not that different in length. It really isn't saving you much.

I suppose you can try overloading an operator to get something to the
effect you want.
On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift-evolution <
swift-evolution@swift.org> wrote:

> Exactly! It's not an earth-shattering pain, but it would be nice to have
> clean type safety there.
>
> > On Dec 16, 2016, at 4:01 PM, Charlie Monroe 
> wrote:
> >
> >
> >>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I would like to be able to create a URL literal that is compile-time
> >>> checked for correct format. This would help avoid code like this:
> >>>
> >>>  let url: URL = URL(string: "https://example.com";)!
> >>>
> >>> The cleanest way I can think of doing that would be to introduce a new
> >>> macro structure similar to #selector, though I'm open to other ideas.
> >>> I would think it should take a quoted literal string to avoid
> >>> problems. That would look like this:
> >>>
> >>>  let url: URL = #url("https://example.com";)
> >>>
> >>> What does everyone think of that idea?
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >>
> >> I’d like to see something like that for file path URLs. For something
> so commonly used, URL(fileURLWithPath:) is obnoxiously verbose.
> >>
> >> Charles
> >
> > Yes, but it's not a nullable initializer. With URL(string:) the
> incredible pain is that even compile-time URLs to your own website are
> nullable URL? and you need to force-unwrap them.
> >
> >>
> >> ___
> >> 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] adding automated-testing of uncompilable features in XCTest

[Derrick Ho via swift-evolution]

Use protocols

{get}
Can be used for let

{get set}
Can be used for var
On Thu, Dec 15, 2016 at 1:16 AM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Howdy,
> Thanks, I’ll consider this as an alternative.
> I don’t see that this solves the issues of whether a property on a
> class is let, however.
> -Ben
>
> > On Dec 14, 2016, at 11:41 PM, Derrick Ho  wrote:
> >
> > You might be able to ensure access modifiers by using protocols.
> >
> > If you want to ensure that a class has a property called foo that is
> private you can make a private protocol that specifies a private property
> called foo.
> >
> > This isn't a XCTest but it is a compile time check. If a programmer
> tries to change a private property to public then the the compiler will
> complain.
> >
> > The same can be done with final. Make a protocol with a static method.
> ___
> 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: Expose enum properties backed by bridgeable types to Objective-C

[Derrick Ho via swift-evolution]

You can currently access swift enums from objective c provided that it is
marked @objc and inherits from Int.

Objectivec can not however access a swift enum that inherits from a string.
I've asked the community about how they feel about enabling this but there
was little to no response.
On Thu, Dec 15, 2016 at 1:06 AM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> MOTIVATION:
>
> Many Cocoa classes which allow the user to choose from a list of items,
> such as NSPopUpButton, NSSegmentedControl, and NSTabView, offer the ability
> to bind the view to an integer or string in the model via KVO, through
> bindings such as “Selected Tag”, “Selected Index”, “Selected Identifier”,
> and the like. Since it can be tough to remember all the tags and whatnot
> that are associated with each view, it’s usually been helpful to create an
> enum to keep track of them… until now, since Objective-C cannot see Swift
> enums, and therefore they cannot be marked ‘dynamic’ for KVO.
>
> One can work around that by declaring two properties, one of which wraps
> the other, like this:
>
> enum SortMethod: Int {
> case byName = 0
> case bySize = 1
> case byModificationDate = 2
> }
>
> var sortMethod: SortMethod {
> willSet { self.willChangeValue(forKey: “sortMethod”) }
> didSet { self.didChangeValue(forKey: “sortMethod”) }
> }
>
> @objc(sortMethod) private dynamic var objcSortMethod: Int {
> get { return self.sortMethod.rawValue }
> set(newValue) { self.sortMethod = SortMethod(rawValue: newValue)! }
> }
>
> However, this is cumbersome.
>
> PROPOSED SOLUTION:
>
> I propose that if an property is typed to an enum, and that enum is backed
> by an Objective-C-bridgeable type, the property should be visible to
> Objective-C as its underlying type. So, for example, if you simply declared
> “var sortMethod: SortMethod” with the @objc attribute or the ‘dynamic’
> keyword, it would generate the longer code shown above. This would allow
> easy binding of UI elements in .xib files to enums in your model.
>
> ALTERNATIVES CONSIDERED:
>
> We could introduce some sort of annotation allowing the user to specify a
> default case in the event that Objective-C tried to set the property to a
> value not covered in the enum, instead of just crashing. However, doing
> such a thing is almost always the result of a programmer error, so I do not
> consider this of high importance.
>
> Charles
>
> ___
> 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] adding automated-testing of uncompilable features in XCTest

[Derrick Ho via swift-evolution]

You might be able to ensure access modifiers by using protocols.

If you want to ensure that a class has a property called foo that is
private you can make a private protocol that specifies a private property
called foo.

This isn't a XCTest but it is a compile time check. If a programmer tries
to change a private property to public then the the compiler will complain.

The same can be done with final. Make a protocol with a static method.



On Wed, Dec 14, 2016 at 8:42 AM Jeremy Pereira via swift-evolution <
swift-evolution@swift.org> wrote:

> The Swift compiler can give you the information that you want.
>
> Here is what you can do:
>
> Write a Swift source file that creates an instance of the type you want to
> test and then tries to access each of the private members.
>
> Write a shell script to compile this source file i a module with the file
> the type is defined in. Have it capture all the error messages by
> redirecting stderr and then count them. If it doesn’t have the right
> number, have the shell script emit a message that looks like a Swift error
> message.
>
> Install the script in a run script build phase. Now you will get an error
> every time one of your private properties or methods loses its access
> modifier.
>
> Personally, I wouldn’t bother. Any test to make sure that private members
> are private requires a separately maintained list of the private members.
> If somebody isn’t disciplined enough to add the word “private” to the
> beginning of a definition, they almost certainly aren’t going to bother
> updating a separate list. And the consequences of omitting “private” are
> only that the module has visibility of it. That’s not a huge deal.
>
>
> > On 13 Dec 2016, at 15:57, Benjamin Spratling via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Howdy,
> >
> > If my immediate goal were to verify private member values at
> intermediate steps in some process, which is the concept under
> consideration in the article you provided, I could access their values with
> a Mirror.
> >
> > That's not my immediate goal.  My immediate goal is to falsify that the
> property is private.  The logic in the article asserts that a member is
> private, then asserts that because the member is private we do not need to
> test it.  But it fails to provide an automated test that the member is
> indeed private and remains so.  To accomplish that goal without an
> automated unit test is painstakingly tedious for a human.
> >
> > And as to whether the logic in the article is correct, assuming its
> assumptions are true, it is still only one kind of testing.  Depending on
> the field it might be called "interface" or "black box" testing, and they
> rightly call that out.  But it would not be considered to be the only kind
> of testing which needs to be done.
> >
> > -Ben
> >
> > Sent from my iPhone.
> >
> > On Dec 13, 2016, at 1:35 AM, Jean-Daniel  wrote:
> >
> >> An interesting reading about testing private members:
> >>
> >> https://cocoacasts.com/how-to-unit-test-private-methods-in-swift/
> >>
> >>
> >>> Le 12 déc. 2016 à 06:10, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >>>
> >>> It bugs me as well that we can not test private components using
> XCTest. Objective-c never had this problem since privacy doesn't exist. I
> would like to see a version of XCTest that allows us to test every
> component.
> >>>
> >>>
> >>> On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via
> swift-evolution  wrote:
> >>> Howdy,
> >>> I’d like to see how much interest there is for adding these to
> the XCTest module.  If I have missed some pro or con, or missed a technical
> point, your feedback is welcome before I go to the lengths to draw up a
> formal proposal.
> >>>
> >>>
> >>> There are several features of Swift which cannot be effectively
> automated-tested.
> >>> For instance, when a type or one of its members is private or file
> private, an outside test suite cannot access it, and the information that
> the type is private is not included in a Mirror.  There are similar
> concerns for testability with internal, and public access levels.  Tests
> can be written ensuring these access levels are >= some level, but not ==
> or < some level.  In other words the very usefulness of these features
> cannot be tested.
> >>>
> >>> Other attributes to be tested in this way are:
> >>>
> >>> - Mutability of a member.  No automated te

Re: [swift-evolution] Nongeneric classes that inherit from generic classes not visible from objc

[Derrick Ho via swift-evolution]

Swift generics are swift only

Objective-c lightweight generics are not true generics but rather just
annotation that helps with interoperability.

Even though you are subclassing a generic class into a supposed non-generic
type it is still a generic. Inheritance follows an is-a relationship and
the subclass gets its generic genes from the parent class.


On Wed, Dec 14, 2016 at 1:06 PM Davide Mendolia via swift-evolution <
swift-evolution@swift.org> wrote:

> Ok, I understand. But my use case is adding functionality to obj-c class
> provided by the ios sdk through generics. As I see it's not something
> possible, I will go for an implementation that's it's not checking the type
> through generic at compile time.
>
> On Wed, Dec 14, 2016 at 6:56 PM Jordan Rose  wrote:
>
> Right. Even though the class you want to expose isn't generic, its
> superclass is, and Objective-C needs to know the whole inheritance chain in
> order to use the class in any meaningful way.
>
> Depending on what your use case is, you may be able to work with a @objc
> protocol instead (either imported or defined in Swift).
>
> Jordan
>
>
> On Dec 14, 2016, at 08:47, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Davide,
>
> AFAIK this is not (easily) possible (please, correct me someone if I'm
> wrong) since Swift's generics aren't "lightweight" as ObjC generics are.
>
> In ObjC, no matter what you use for the generics, you still have just 1
> class that handles all call:
>
> @interface MyClass : NSObject
> @end
>
> @class A, B;
>
> NSLog(@"%@", NSStringFromClass([MyClass self])); // MyClass
> NSLog(@"%@", NSStringFromClass([MyClass self])); // MyClass
>
> [MyClass self] == [MyClass self]; // YES
>
> In Swift, when you compile the generic class, a class is generated for
> each type you use - example:
>
> class MyClass {}
> class A {}
> class B {}
>
> NSStringFromClass(MyClass.self) // _TtGC14__lldb_expr_417MyClassCS_1*A*
> _
> NSStringFromClass(MyClass.self) // _TtGC14__lldb_expr_417MyClassCS_1*B*
> _
>
> MyClass.self == MyClass.self // false
>
> This makes what you suggest very complicated.
>
> On Dec 14, 2016, at 2:47 PM, Davide Mendolia via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> Maybe this has been asked before but I couldn't find it.
>
> I would like to be able to give visibility of non-generic subclass of a
> generic class to obj-c. Is there any limitation of the compiler knowing
> that the type of the non-generic type is closed, to generate a compatible
> version for obj-c?
>
> Code Example:
>
> class SwiftSuperType : NSObject {
>
> }
>
> class NonGenericClass2: SwiftSuperType {
>
> }
>
> Or with a obj-c super class:
>
> @interface ObjcSuperType> : NSObject
>
> @end
>
> class NonGenericClass: ObjcSuperType {
>
> }
>
>
> Actual Behaviour:
>
> Non-generic classes are not visible in obj-c. If adding the @objc notation
> we get the following error.
>
> Actual error message:
> Generic subclasses of '@objc' classes cannot have an explicit '@objc'
> attribute because they are not directly visible from Objective-C
>
> regards,
>
> --
> Davide Mendolia
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

[Derrick Ho via swift-evolution]

It bugs me as well that we can not test private components using XCTest.
Objective-c never had this problem since privacy doesn't exist. I would
like to see a version of XCTest that allows us to test every component.


On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Howdy,
> I’d like to see how much interest there is for adding these to the
> XCTest module.  If I have missed some pro or con, or missed a technical
> point, your feedback is welcome before I go to the lengths to draw up a
> formal proposal.
>
>
> There are several features of Swift which cannot be effectively
> automated-tested.
> For instance, when a type or one of its members is private or file
> private, an outside test suite cannot access it, and the information that
> the type is private is not included in a Mirror.  There are similar
> concerns for testability with internal, and public access levels.  Tests
> can be written ensuring these access levels are >= some level, but not ==
> or < some level.  In other words the very usefulness of these features
> cannot be tested.
>
> Other attributes to be tested in this way are:
>
> - Mutability of a member.  No automated test can be written which verifies
> that a function cannot be called on a let struct, or that a property cannot
> be set at a specific access level.
>
> - That a stored property is weak or unowned.
>
> - That a class or class member is “final”
>
> These are concepts which need to be unit-tested to ensure good design is
> not broken, but do not need to be included in a release build, so including
> them in the XCTest framework seems like an appropriate destination.
> Moreover, the information for all of these features exists in the
> .swiftmodule files, which are included in test builds, but sometimes
> stripped for release.
>
> Examples:
> Since these features inherently have to do with testing features which
> cannot be stated in compiled code, I recommend specifying names with
> Strings.  Here are some examples of what I would like to write in my test
> code:
>
> XCTAssertEqual(
> Module(named:”SingMusicLayout”)?.type(named:”NoteSetter”)?.property(named:”session”)?.accessLevel,
> .private)
>
> XCTAssertEqual(
> Module(named:”SingMusicLayout”)?.type(named:”ScaleLayout”)?.method(named:”baselineOffset(for:PitchInterval)->CGFloat”)?.mutable,
> false)
>
>
> Alternatives:
> 1.  Building an independent .swiftmodule parser in a single Swift
> module, which can be included in test builds.
> + Can be distributed independently from Swift sources,
> requiring 0 buy-in from Swift community
> + requires a single additional module for the test.
> - Depends on ever-changing binary interface.
> : Intractable, not DRY
>
> 2.  Use existing sourcekitd.
> + harnesses changes in the compiler’s source code with
> SourceKit
> - cannot be run in a test suite without extensive work by
> user to configure bundles explicitly.
> Exceptionally poor user experience
> : sourcekitd XPC architecture only works on macOS
>
> 3.  Use a standalone tool for tests
> + harnesses changes in the compiler’s source code with
> SourceKit
> + no installation in user’s source code necessary
> : cannot be effectively run by SPM test infrastructure
>
> ___
> 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: Allows operator overloads in struct or classes based on return type

[Derrick Ho via swift-evolution]

You may want to add the specific error to your proposal.

*error: member operator '•|' must have at least one argument of type
'NonEmptyArray'*

*public static func •|(lhs: Element, rhs: [Element]) ->
NonEmptyArray*

On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho  wrote:

> I placed he code you wrote in the proposal in playgrounds and it works
> perfectly.  (reproduced below). Overloading operators used to only happen
> globally and since swift 3 they allowed you to put then inside the
> class/struct
>
> public struct NonEmptyArray {
>
> fileprivate var elements: Array
>
> fileprivate init(array: [Element]) {
> self.elements = array
> }
> }
>
> //Overload 1
> public func •|(lhs: Element, rhs: [Element]) -> 
> NonEmptyArray {
> return NonEmptyArray(array: rhs + [lhs])
> }
>
> //Overload 2
> public func •|(lhs: Element, rhs:  NonEmptyArray) -> 
> NonEmptyArray {
> return NonEmptyArray(array: [lhs] + rhs.elements)
> }
>
> //Overload 3
> public func •|(lhs: NonEmptyArray, rhs: 
> NonEmptyArray) -> NonEmptyArray {
> return NonEmptyArray(array: lhs.elements + rhs.elements)
> }
>
>
> However, as you have detailed when you place those overloads inside the
> struct/class, it does not work.  Actually I get an error that says that at
> least ONE of the arguments needs to be the same type.  In this case one of
> them needs to be NonEmptyArray. It is clearly not a bug, but
> rather a swift rule.
>
> My recommendation is to just keep those overloads as global.  Is there a
> particular advantage to putting them inside the struct/class?
>
>
>
> On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I have written a small proposal that would allow overloads of operators in
> structs/classes non only based on the types of the operands but on the
> return type as well.
>
> Please let me know you thoughts,
> /Tommaso
>
>
> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>
>
> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just
> not aware of the reasoning.
>
>
> Actually, since the error message correctly parses the code, it probably
> *is* intentional… I don’t see the problem, myself, but I guess I’d have
> to know why it’s considered an error before judging whether I think we
> should remove the restriction.
>
> - Dave Sweeris
> ___
> 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: Allows operator overloads in struct or classes based on return type

[Derrick Ho via swift-evolution]

I placed he code you wrote in the proposal in playgrounds and it works
perfectly.  (reproduced below). Overloading operators used to only happen
globally and since swift 3 they allowed you to put then inside the
class/struct

public struct NonEmptyArray {

fileprivate var elements: Array

fileprivate init(array: [Element]) {
self.elements = array
}
}

//Overload 1
public func •|(lhs: Element, rhs: [Element]) ->
NonEmptyArray {
return NonEmptyArray(array: rhs + [lhs])
}

//Overload 2
public func •|(lhs: Element, rhs:  NonEmptyArray) ->
NonEmptyArray {
return NonEmptyArray(array: [lhs] + rhs.elements)
}

//Overload 3
public func •|(lhs: NonEmptyArray, rhs:
NonEmptyArray) -> NonEmptyArray {
return NonEmptyArray(array: lhs.elements + rhs.elements)
}


However, as you have detailed when you place those overloads inside the
struct/class, it does not work.  Actually I get an error that says that at
least ONE of the arguments needs to be the same type.  In this case one of
them needs to be NonEmptyArray. It is clearly not a bug, but
rather a swift rule.

My recommendation is to just keep those overloads as global.  Is there a
particular advantage to putting them inside the struct/class?



On Sat, Dec 10, 2016 at 8:36 PM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I have written a small proposal that would allow overloads of operators in
> structs/classes non only based on the types of the operands but on the
> return type as well.
>
> Please let me know you thoughts,
> /Tommaso
>
>
> https://github.com/blender/swift-evolution/blob/proposal/overloads-return-type/-allow-operator-overloads-in-structs-or-classes-based-on-return-type.md
>
>
> That seems like a bug to me… Dunno, maybe it’s intentional and I’m just
> not aware of the reasoning.
>
>
> Actually, since the error message correctly parses the code, it probably
> *is* intentional… I don’t see the problem, myself, but I guess I’d have
> to know why it’s considered an error before judging whether I think we
> should remove the restriction.
>
> - Dave Sweeris
> ___
> 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] Any consideration for directoryprivate as a compliment to fileprivate?

[Derrick Ho via swift-evolution]

-1 we don't need any more access modifiers. We already have an excessive
amount: 5
On Thu, Dec 8, 2016 at 12:55 PM Jim Malak via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Tino,
> This is my first use of this forum. I certainly did not mean to cause pain
> for anyone.
> At Gonzalo's invitation I have looked over the thread for his proposal and
> I am withdrawing my request and backing his with a very heavy +1.
> The group has done an amazing job with the open source development of
> Swift. Though this email approach may cause some problems, all of you have
> advanced the language tremendously in a very short period of time.
> If I have offended anyone I ask their forgiveness. Since you mentioned it
> I will state that the Xcode approach to project groups is one that I have
> yet to understand the merit of.
> Gonzalo: please let me know how I can assist you.
> - Jim
>
> _
> From: Tino Heth <2...@gmx.de>
> Sent: Thursday, December 8, 2016 12:08 PM
>
> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a
> compliment to fileprivate?
> To: Jim Malak 
> Cc: 
>
>
> I guess it's just coincidence, but this thread about "directoryprivate"
> did start while the thread about "typeprivate" (which ended up as a general
> discussion) is fading away without real results…
>
> To me, this looks like an indication for two* things:
>
> a) Access levels are broken** in Swift 3
>
> b) The tool used for discussion (mailing list) is broken** as well
>
> Right now, I'm in the mood to write a rant about b) (that might change
> until I have time to do so ;-), but returning back to topic, I really don't
> think adding more and more levels with more and more magic words is a bad
> idea.
> Additionally, "directoryprivate" will be really painful due to the way
> Xcode deals with the filesystem (although that might be an argument for
> adding it, as imho Xcode needs improvement in this aspect anyways ;-)
>
> - Tino
>
> * three things to be honest; but the last one would be to controversial
> for a half sentence without explanation
>
> ** actually, I think "broken" is way to hard — but judging from past
> experience, I come to the sad conclusion that provoking statements are
> better to drive discussion ;-)
>
> ___
> 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