Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

Most of the cases I can think of for @required are for clean up mechanisms
triggered by the closure and as such would only need to be called once.

So in theory @once may be able to cover this case, in a sense I guess you
could argue @once is just a subset of @required it would check it is
exactly once. But @required is about making sure it is called at all.

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 17 August 2016 at 13:43, Brent Royal-Gordon <br...@architechies.com>
wrote:

> > On Aug 16, 2016, at 12:44 PM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > That sounds fair, the closure that function returns could trigger a
> runtime warning when it detects the closure has be deallocated without
> being triggered (or even mutliple times but ofc not the focus for this
> proposal)
>
> You know, I'm thinking about that "multiple times" thing...
>
> We know we want a @once (formerly @noescape(once)) for closures which are
> guaranteed to be called exactly once. This would help us with initializing
> variables, and especially properties, from a closure. Perhaps we should
> extend that to support @escaping @once. Would that handle these use cases?
> Are there use cases for @required where you expect more than one call? I
> think all of the use cases we've discussed here—ending handlers and
> such—should only be called once.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

In this case the @required callback is something *all* implementations
should use for the mentioned reasons (memory leaks etc) just to clarify :).

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 17 August 2016 at 11:31, Haravikk  wrote:

>
> > On 17 Aug 2016, at 02:49, Boris Wang via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Why the callback is special ?
> >
> > The compiler should has a warning for unused parameters of function.
> >
> > I think this is enough. More works should be leaved for a lint tool.
>
> Actually I think that that kind of warning should be left for linters as
> well; a protocol might define parameters that not all implementations use,
> or a type may define a method with a parameter that is intended only for
> future use (to avoid defining an overload later), these aren't necessarily
> problems.
>
> Also, how do you want to define unused? I suppose a non-escaping closure
> is unused if it's never called (since it can't be stored), but that doesn't
> guarantee that it *will* be called, which is the point of this proposal,
> i.e- a non-escaping closure may be part of a loop that may not execute,
> which is fine since it has no requirement to be used in every call, only
> that it isn't stored.
>
> So yeah, even if a warning like this could be done right, I'm not sure it
> replaces the case put forward for @required.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

​Thats true, my only concern with that is if the user disables that
warning.​

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 17 August 2016 at 02:49, Boris Wang <kona.m...@gmail.com> wrote:

> Why the callback is special ?
>
> The compiler should has a warning for unused parameters of function.
>
> I think this is enough. More works should be leaved for a lint tool.
>
>
> James Campbell via swift-evolution <swift-evolution@swift.org>于2016年8月17日
> 周三06:39写道：
>
>> ​I'm not sure about that last question, I guess someone who knows more
>> about it than me could answer.​
>>
>> *___*
>>
>> *James⎥Lead Hustler*
>>
>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>> <http://supmenow.com>*
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>>
>> On 16 August 2016 at 23:37, James Campbell <ja...@supmenow.com> wrote:
>>
>>> @noescape is a hint that the callback will only be called once and
>>> allows compiler to optimise, we may or may not be able to combine @required
>>> functionality into that but it looks like it was rejected for now.
>>>
>>> @required is a compiler hint / sanity check to enforce that the callback
>>> is actually called once by the developer. There is no focus on any compiler
>>> enhancements other than 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] Required Callback

[James Campbell via swift-evolution]

​I'm not sure about that last question, I guess someone who knows more
about it than me could answer.​

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 23:37, James Campbell  wrote:

> @noescape is a hint that the callback will only be called once and allows
> compiler to optimise, we may or may not be able to combine @required
> functionality into that but it looks like it was rejected for now.
>
> @required is a compiler hint / sanity check to enforce that the callback
> is actually called once by the developer. There is no focus on any compiler
> enhancements other than that.
> ​
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

Proposed ! https://github.com/apple/swift-evolution/pull/502

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 20:44, James Campbell <ja...@supmenow.com> wrote:

> That sounds fair, the closure that function returns could trigger a
> runtime warning when it detects the closure has be deallocated without
> being triggered (or even mutliple times but ofc not the focus for this
> proposal)
>
>
>
> *___*
>
> *James⎥Lead Hustler*
>
> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
> <http://supmenow.com>*
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 16 August 2016 at 18:39, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>> One alternative that comes to mind:
>>
>> The @escaping stuff came with a helper function, withoutActuallyEscaping,
>> to deal with attribute mismatches. Perhaps we could have the same here, for
>> consistency, something like withActuallyInvoking?
>>
>> On Tue, Aug 16, 2016 at 12:05 Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>
>>> Well, the callsite @required would be what I call your escape hatch :)
>>>
>>> Hmm, lemme think on this...
>>> On Tue, Aug 16, 2016 at 11:59 James Campbell <ja...@supmenow.com> wrote:
>>>
>>>> It would though, look :) :
>>>>
>>>> Backend.run() { requiredCallback in
>>>>
>>>>  NonAnotatedModuled({
>>>>
>>>> //We send a anon closure to the module and we call the callback with a
>>>> required specifier to indicate to the compiler it will be called :)
>>>> @required requiredCallback()
>>>> })
>>>> }
>>>>
>>>> This would be the same as this:
>>>>
>>>>
>>>> Backend.run() { requiredCallback in
>>>>
>>>>  AnotatedModuled(requiredCallback)
>>>> }
>>>>
>>>> And this:
>>>>
>>>>
>>>> Backend.run() { requiredCallback in
>>>>
>>>> @required requiredCallback()
>>>> }
>>>>
>>>> *___*
>>>>
>>>> *James⎥Lead Hustler*
>>>>
>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>> <http://supmenow.com>*
>>>>
>>>> *Sup*
>>>>
>>>> *Runway East *
>>>>
>>>> *10 Finsbury Square*
>>>>
>>>> *London*
>>>>
>>>> * EC2A 1AF *
>>>>
>>>> On 16 August 2016 at 17:55, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>
>>>>> Wait, doesn't work. Your anonymous closure would then be dinged for
>>>>> not satisfying the requirement. Turtles all the way down. Still need an
>>>>> escape hatch.
>>>>>
>>>>> On Tue, Aug 16, 2016 at 11:54 James Campbell <ja...@supmenow.com>
>>>>> wrote:
>>>>>
>>>>>> I'll write up a draft proposal :) I think we have something nice :)
>>>>>>
>>>>>> *___*
>>>>>>
>>>>>> *James⎥Lead Hustler*
>>>>>>
>>>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>>>> <http://supmenow.com>*
>>>>>>
>>>>>> *Sup*
>>>>>>
>>>>>> *Runway East *
>>>>>>
>>>>>> *10 Finsbury Square*
>>>>>>
>>>>>> *London*
>>>>>>
>>>>>> * EC2A 1AF *
>>>>>>
>>>>>> On 16 August 2016 at 17:54, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>>
>>>>>>> Nicer still!
>>>>>>>
>>>>>>> On Tue, Aug 16, 2016 at 11:53 James Campbell <ja...@supmenow.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I guess that would make sense and you could wrap the callback up in
>>>>>>>> a anon-closure if the module hadn't adpated the @required property so 
>>>>>>>> you
>>>>>>>> get both compatibility, safety and clarity.
>>>>>>>>
>&g

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

That sounds fair, the closure that function returns could trigger a runtime
warning when it detects the closure has be deallocated without being
triggered (or even mutliple times but ofc not the focus for this proposal)



*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 18:39, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> One alternative that comes to mind:
>
> The @escaping stuff came with a helper function, withoutActuallyEscaping,
> to deal with attribute mismatches. Perhaps we could have the same here, for
> consistency, something like withActuallyInvoking?
>
> On Tue, Aug 16, 2016 at 12:05 Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>> Well, the callsite @required would be what I call your escape hatch :)
>>
>> Hmm, lemme think on this...
>> On Tue, Aug 16, 2016 at 11:59 James Campbell <ja...@supmenow.com> wrote:
>>
>>> It would though, look :) :
>>>
>>> Backend.run() { requiredCallback in
>>>
>>>  NonAnotatedModuled({
>>>
>>> //We send a anon closure to the module and we call the callback with a
>>> required specifier to indicate to the compiler it will be called :)
>>> @required requiredCallback()
>>> })
>>> }
>>>
>>> This would be the same as this:
>>>
>>>
>>> Backend.run() { requiredCallback in
>>>
>>>  AnotatedModuled(requiredCallback)
>>> }
>>>
>>> And this:
>>>
>>>
>>> Backend.run() { requiredCallback in
>>>
>>> @required requiredCallback()
>>> }
>>>
>>> *___*
>>>
>>> *James⎥Lead Hustler*
>>>
>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>> <http://supmenow.com>*
>>>
>>> *Sup*
>>>
>>> *Runway East *
>>>
>>> *10 Finsbury Square*
>>>
>>> *London*
>>>
>>> * EC2A 1AF *
>>>
>>> On 16 August 2016 at 17:55, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>
>>>> Wait, doesn't work. Your anonymous closure would then be dinged for not
>>>> satisfying the requirement. Turtles all the way down. Still need an escape
>>>> hatch.
>>>>
>>>> On Tue, Aug 16, 2016 at 11:54 James Campbell <ja...@supmenow.com>
>>>> wrote:
>>>>
>>>>> I'll write up a draft proposal :) I think we have something nice :)
>>>>>
>>>>> *___*
>>>>>
>>>>> *James⎥Lead Hustler*
>>>>>
>>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>>> <http://supmenow.com>*
>>>>>
>>>>> *Sup*
>>>>>
>>>>> *Runway East *
>>>>>
>>>>> *10 Finsbury Square*
>>>>>
>>>>> *London*
>>>>>
>>>>> * EC2A 1AF *
>>>>>
>>>>> On 16 August 2016 at 17:54, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>
>>>>>> Nicer still!
>>>>>>
>>>>>> On Tue, Aug 16, 2016 at 11:53 James Campbell <ja...@supmenow.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I guess that would make sense and you could wrap the callback up in
>>>>>>> a anon-closure if the module hadn't adpated the @required property so 
>>>>>>> you
>>>>>>> get both compatibility, safety and clarity.
>>>>>>>
>>>>>>> *___*
>>>>>>>
>>>>>>> *James⎥Lead Hustler*
>>>>>>>
>>>>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>>>>> <http://supmenow.com>*
>>>>>>>
>>>>>>> *Sup*
>>>>>>>
>>>>>>> *Runway East *
>>>>>>>
>>>>>>> *10 Finsbury Square*
>>>>>>>
>>>>>>> *London*
>>>>>>>
>>>>>>> * EC2A 1AF *
>>>>>>>
>>>>>>> On 16 August 2016 at 17:50, Haravikk <swift-evolut...@haravikk.me>
>>>>>>> wrote:
>>>>>>>
>

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

It would though, look :) :

Backend.run() { requiredCallback in

 NonAnotatedModuled({

//We send a anon closure to the module and we call the callback with a
required specifier to indicate to the compiler it will be called :)
@required requiredCallback()
})
}

This would be the same as this:


Backend.run() { requiredCallback in

 AnotatedModuled(requiredCallback)
}

And this:


Backend.run() { requiredCallback in

@required requiredCallback()
}

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 17:55, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> Wait, doesn't work. Your anonymous closure would then be dinged for not
> satisfying the requirement. Turtles all the way down. Still need an escape
> hatch.
>
> On Tue, Aug 16, 2016 at 11:54 James Campbell <ja...@supmenow.com> wrote:
>
>> I'll write up a draft proposal :) I think we have something nice :)
>>
>> *___*
>>
>> *James⎥Lead Hustler*
>>
>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>> <http://supmenow.com>*
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>>
>> On 16 August 2016 at 17:54, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>
>>> Nicer still!
>>>
>>> On Tue, Aug 16, 2016 at 11:53 James Campbell <ja...@supmenow.com> wrote:
>>>
>>>> I guess that would make sense and you could wrap the callback up in a
>>>> anon-closure if the module hadn't adpated the @required property so you get
>>>> both compatibility, safety and clarity.
>>>>
>>>> *___*
>>>>
>>>> *James⎥Lead Hustler*
>>>>
>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>> <http://supmenow.com>*
>>>>
>>>> *Sup*
>>>>
>>>> *Runway East *
>>>>
>>>> *10 Finsbury Square*
>>>>
>>>> *London*
>>>>
>>>> * EC2A 1AF *
>>>>
>>>> On 16 August 2016 at 17:50, Haravikk <swift-evolut...@haravikk.me>
>>>> wrote:
>>>>
>>>>>
>>>>> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution <
>>>>> swift-evolution@swift.org> wrote:
>>>>>
>>>>> I can see the use case, but it'd be annoying (or, impossible) to work
>>>>> around if I intend to call `end` by passing it to a helper function in
>>>>> another (let's say, precompiled) module. There's no way for the compiler 
>>>>> to
>>>>> inspect that `end` is always called by that other module, and if calling
>>>>> `end` twice causes bad things to happen, I'm totally out of luck. You'd
>>>>> need a companion annotation to pass along the requirement to the callee, 
>>>>> or
>>>>> some sort of force-unrequire, but the latter can't have teeth (i.e. can't
>>>>> enforce at runtime) if the closure is escaping.
>>>>> On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution <
>>>>> swift-evolution@swift.org> wrote:
>>>>>
>>>>>> It would be handy if a callback could be marked as required with an
>>>>>> optional descriptive message i.e
>>>>>>
>>>>>> class BackgroundTask {
>>>>>>  func run(end: @required("You must call end otherwise iOS will
>>>>>> penalise your app for being a bad citizen") () -> Void)
>>>>>> }
>>>>>>
>>>>>> That was the developer can comunicate the bad things that can happen
>>>>>> if this callback isn't called such as iOS peanlizing them for not ending 
>>>>>> a
>>>>>> background task or perhaps memory leaks caused by clean up code unable to
>>>>>> be triggered.
>>>>>>
>>>>>
>>>>> Could this not just behave in the same way as @noescape, in which case
>>>>> you can pass the closure on to other functions so long as they also have
>>>>> the @noescape attribute? In this case passing it as a parameter to another
>>>>> method with the @required attribute would be equivalent to calling it
>>>>> directly (since you know the other method must eventually call it).
>>>>>
>>>>
>>>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

I'll write up a draft proposal :) I think we have something nice :)

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 17:54, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> Nicer still!
>
> On Tue, Aug 16, 2016 at 11:53 James Campbell <ja...@supmenow.com> wrote:
>
>> I guess that would make sense and you could wrap the callback up in a
>> anon-closure if the module hadn't adpated the @required property so you get
>> both compatibility, safety and clarity.
>>
>> *___*
>>
>> *James⎥Lead Hustler*
>>
>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>> <http://supmenow.com>*
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>>
>> On 16 August 2016 at 17:50, Haravikk <swift-evolut...@haravikk.me> wrote:
>>
>>>
>>> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> I can see the use case, but it'd be annoying (or, impossible) to work
>>> around if I intend to call `end` by passing it to a helper function in
>>> another (let's say, precompiled) module. There's no way for the compiler to
>>> inspect that `end` is always called by that other module, and if calling
>>> `end` twice causes bad things to happen, I'm totally out of luck. You'd
>>> need a companion annotation to pass along the requirement to the callee, or
>>> some sort of force-unrequire, but the latter can't have teeth (i.e. can't
>>> enforce at runtime) if the closure is escaping.
>>> On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>> It would be handy if a callback could be marked as required with an
>>>> optional descriptive message i.e
>>>>
>>>> class BackgroundTask {
>>>>  func run(end: @required("You must call end otherwise iOS will penalise
>>>> your app for being a bad citizen") () -> Void)
>>>> }
>>>>
>>>> That was the developer can comunicate the bad things that can happen if
>>>> this callback isn't called such as iOS peanlizing them for not ending a
>>>> background task or perhaps memory leaks caused by clean up code unable to
>>>> be triggered.
>>>>
>>>
>>> Could this not just behave in the same way as @noescape, in which case
>>> you can pass the closure on to other functions so long as they also have
>>> the @noescape attribute? In this case passing it as a parameter to another
>>> method with the @required attribute would be equivalent to calling it
>>> directly (since you know the other method must eventually call it).
>>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

I guess that would make sense and you could wrap the callback up in a
anon-closure if the module hadn't adpated the @required property so you get
both compatibility, safety and clarity.

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 17:50, Haravikk <swift-evolut...@haravikk.me> wrote:

>
> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I can see the use case, but it'd be annoying (or, impossible) to work
> around if I intend to call `end` by passing it to a helper function in
> another (let's say, precompiled) module. There's no way for the compiler to
> inspect that `end` is always called by that other module, and if calling
> `end` twice causes bad things to happen, I'm totally out of luck. You'd
> need a companion annotation to pass along the requirement to the callee, or
> some sort of force-unrequire, but the latter can't have teeth (i.e. can't
> enforce at runtime) if the closure is escaping.
> On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> It would be handy if a callback could be marked as required with an
>> optional descriptive message i.e
>>
>> class BackgroundTask {
>>  func run(end: @required("You must call end otherwise iOS will penalise
>> your app for being a bad citizen") () -> Void)
>> }
>>
>> That was the developer can comunicate the bad things that can happen if
>> this callback isn't called such as iOS peanlizing them for not ending a
>> background task or perhaps memory leaks caused by clean up code unable to
>> be triggered.
>>
>
> Could this not just behave in the same way as @noescape, in which case you
> can pass the closure on to other functions so long as they also have the
> @noescape attribute? In this case passing it as a parameter to another
> method with the @required attribute would be equivalent to calling it
> directly (since you know the other method must eventually call it).
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Required Callback

[James Campbell via swift-evolution]

I think that tidies it up a lot, that would make it stick out a lot for me
especially when dealing with iOS's app delegate callbacks.

*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 17:29, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> I wonder if we can be a little more elegant:
>
> - no need for an optional message: if the compiler is going to force you
> the implementor to call something, it really doesn't matter why--you just
> call it; any additional explanation can be given in doc comments
>
> - at the implementation site, you the implementor would have to parrot
> @required in the declaration; that in itself wins some clarity (the
> implementor has to know it's required)
>
> - instead of allowing any assignment or reference of the callback to
> satisfy the requirement, either require actual invocation in the body, or
> allow the callback to be called/assigned/whatever with an extra attribute
> @invoked (or whatever the preferred bikeshed)
>
> MyModule(@invoked end)
> // or live dangerously:
> // _ = @invoked end
>
>
> On Tue, Aug 16, 2016 at 09:54 James Campbell <ja...@supmenow.com> wrote:
>
>>
>> I think as long as the end callback is referenced in some way that would
>> still be better than what we have now, if you pass it into your own code
>> but then continue on to not call it then I think it would be fair for the
>> compiler to let you shoot yourself in the foot in that case.
>>
>> Calling end more than once is another case which isn't covered by this
>> proposal.
>>
>> so this:
>>
>> run() { end in
>>
>> }
>>
>> would have an error:
>>
>> but
>>
>> run() end in {
>>  MyModule(end)
>> }
>>
>> would not since we have at least referenced it.
>>
>>
>> *___*
>>
>> *James⎥Lead Hustler*
>>
>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>> <http://supmenow.com>*
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>>
>> On 16 August 2016 at 15:49, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>
>>> I can see the use case, but it'd be annoying (or, impossible) to work
>>> around if I intend to call `end` by passing it to a helper function in
>>> another (let's say, precompiled) module. There's no way for the compiler to
>>> inspect that `end` is always called by that other module, and if calling
>>> `end` twice causes bad things to happen, I'm totally out of luck. You'd
>>> need a companion annotation to pass along the requirement to the callee, or
>>> some sort of force-unrequire, but the latter can't have teeth (i.e. can't
>>> enforce at runtime) if the closure is escaping.
>>> On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>> It would be handy if a callback could be marked as required with an
>>>> optional descriptive message i.e
>>>>
>>>> class BackgroundTask {
>>>>  func run(end: @required("You must call end otherwise iOS will penalise
>>>> your app for being a bad citizen") () -> Void)
>>>> }
>>>>
>>>> That was the developer can comunicate the bad things that can happen if
>>>> this callback isn't called such as iOS peanlizing them for not ending a
>>>> background task or perhaps memory leaks caused by clean up code unable to
>>>> be triggered.
>>>>
>>>> *___*
>>>>
>>>> *James*
>>>>
>>>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>>>> <http://supmenow.com>*
>>>>
>>>> *Sup*
>>>>
>>>> *Runway East *
>>>>
>>>> *10 Finsbury Square*
>>>>
>>>> *London*
>>>>
>>>> * EC2A 1AF *
>>>> ___
>>>> 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] Required Callback

[James Campbell via swift-evolution]

I think as long as the end callback is referenced in some way that would
still be better than what we have now, if you pass it into your own code
but then continue on to not call it then I think it would be fair for the
compiler to let you shoot yourself in the foot in that case.

Calling end more than once is another case which isn't covered by this
proposal.

so this:

run() { end in

}

would have an error:

but

run() end in {
 MyModule(end)
}

would not since we have at least referenced it.


*___*

*James⎥Lead Hustler*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 16 August 2016 at 15:49, Xiaodi Wu <xiaodi...@gmail.com> wrote:

> I can see the use case, but it'd be annoying (or, impossible) to work
> around if I intend to call `end` by passing it to a helper function in
> another (let's say, precompiled) module. There's no way for the compiler to
> inspect that `end` is always called by that other module, and if calling
> `end` twice causes bad things to happen, I'm totally out of luck. You'd
> need a companion annotation to pass along the requirement to the callee, or
> some sort of force-unrequire, but the latter can't have teeth (i.e. can't
> enforce at runtime) if the closure is escaping.
> On Tue, Aug 16, 2016 at 08:39 James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> It would be handy if a callback could be marked as required with an
>> optional descriptive message i.e
>>
>> class BackgroundTask {
>>  func run(end: @required("You must call end otherwise iOS will penalise
>> your app for being a bad citizen") () -> Void)
>> }
>>
>> That was the developer can comunicate the bad things that can happen if
>> this callback isn't called such as iOS peanlizing them for not ending a
>> background task or perhaps memory leaks caused by clean up code unable to
>> be triggered.
>>
>> *___*
>>
>> *James*
>>
>> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
>> <http://supmenow.com>*
>>
>> *Sup*
>>
>> *Runway East *
>>
>> *10 Finsbury Square*
>>
>> *London*
>>
>> * EC2A 1AF *
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[James Campbell via swift-evolution]

Personally I think a great compromise is just forcing the user to use the
`override` keyword when subclassing in these cases. That way the library
maker can mark classes that aren't supported or are internal and ideally
shouldn't be used by the programmer.

However we shouldn't baby sit programmers, we are smart people after all.
So if there is a huge catastrophic bug that just happens to be easily
solvable by subclassing or whatever then we should allow them to do so.

An `override` keyword would be a great compromise, take this class:

public class NonSubclassableParentClass {

}


If the programmer subclasses it normally, the compiler will throw an error
telling them to use the `override` keyword to subclass non-subclassble
classes:

override class  MySubclass: NonSubclassableParentClass {

}


Now there is a clear indicator that we are doing something not safe or
ideal here. This is similar how the "!" in IUO indicates we have a unsafe
value. We are grown-ups we should be able to know when to subclass but this
doesn't mean there couldn't be something like this to indicate to the user
that they may want to revaluate this in the future.

So in the future other programmers can see this marker and think "Oh we are
using this class in a non recommended way, so when it breaks when I upgrade
the library it's our fault." hopefully making them continue to upgrade
rather than not upgrading because it breaks "my subclass".

Whats great about this feature is it also allows linters or the compiler to
also show warnings when this is used as well, that way those of us that are
bugged by the amount of warnings we have in our app can endevour to fix it.

In Ruby there is a convention to have these sort of monkey patches and
subclasses to fix bugs in a special folder with "_ext" after it to indicate
that this an extension to a class from a library, this indicates to the
programmer that it's something we should ideally remove as soon as the app
can work without that hack.

So I can't see why we can't have this `override` keyword to tell the
library developer that we like to live life on the edge a litte ;)


*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 8 July 2016 at 22:14, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe
> there would have been significant benefits to Apple's platforms and
> ecosystem.  The reasons for believing (or not believing) this have been
> discussed in depth so there isn't a need to rehash them now.
>
> I'm not asking for reasons but for a single persuasive example…
>
> It is easy to claim that everything will be better if we add restrictions,
> but so far, I haven't heard of any real problems cause by the current
> defaults:
> The motivation to change them is not because of actual experience, it's
> just the trendy opinion that inheritance is evil.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[James Campbell via swift-evolution]

-0.5 I think preventing subclassing is a bad idea, sometimes there are bugs
which can only be resolved by subclassing and this removes a lot of power
from app makers.

On 6 July 2016 at 13:23, Jacopo Andrea Giola via swift-evolution <
swift-evolution@swift.org> wrote:

> >   * What is your evaluation of the proposal?
>
> Unless someone can prove to me why we wouldn't need this for fixing bugs I
> still thing this is only a good system to hint at the developer that they
> shouldn't be using this class unless they have to.
>
> I could envision the compiler using the overide keyword to force the
> developer to acknowledge they are using a non-reccomended class like so:
>
> // This class implements a polyfill which fixes a bug in the keychain class
> override class PolyfillForKeychainBug: Keychain {
>
> }
>
> Without this the compiler would throw an error "Non-open class can't be
> overridden without `override` keyword"
>
> >   * Does this proposal fit well with the feel and direction of Swift?
>
> ​It does in terms of safety but not in terms of simplicity.​
>
>
> >   * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> ​It works like Java but I never liked final​
>
>

> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I’ve read the proposal
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

[James Campbell via swift-evolution]

Maybe a way we could opt in is by only doing this for enums with out
turples?

i.e

enum ABTestingBrah {

case A
case B

}

I'm not sure if enums that take turples would need this functionality.

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 5 July 2016 at 11:39, Charlie Monroe <char...@charliemonroe.net> wrote:

> Example:
>
> enum MediaKind {
> case HomeVideo, Movie, MusicVideo, TVShow
>
> var localizedName: String { ... }
> }
>
> let popUpButton: NSPopUpButton = ...
> for kind in MediaKind.allKinds {
> popUpButton.addItemWithTitle(kind.localizedName)
> }
>
> And many, many more.
>
>
> On Jul 5, 2016, at 12:33 PM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Would love a real life scenario of why you would need this.
>
> *___*
>
> *James⎥Head of Trolls*
>
> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
> <http://supmenow.com/>*
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello, this has been proposed multiple times before in different ways.
>>
>> Link to detailed proposal draft:
>>
>> https://github.com/gabriellanata/swift-evolution/blob/master/proposals/-allow-enumerating-cases-in-enumerations.md
>>
>> It is currently not possible to enumerate through all the possible cases
>> of an enumeration object without adding a hardcoded value or recurring to
>> unsafe workarounds. The proposal is to add a method of obtaining an array
>> or set of all the possible cases natively for enumerations without
>> associated values.
>>
>> The proposed solution is to implement a native `.cases` static var for
>> all enumerations without associated values. This would provide a strict
>> type-safe way of enumerating though the possible cases without risking
>> runtime errors. The resulting code is a lot cleaner and less prone to
>> errors caused by forgetting to update the hardcoded values when
>> modifying cases.
>>
>> Resulting code:
>>
>>enum PokemonType {
>>case Fire, Grass, Water, Wind
>>}
>>for pokemonType in PokemonType.cases {
>>// Do stuff
>>}
>>PokemonType.cases.count // Returns 4
>>
>>
>> ---
>> Gabriel
>>
>>
>> ___
>> 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] Allow enumerating cases in enumerations

[James Campbell via swift-evolution]

Would love a real life scenario of why you would need this.

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello, this has been proposed multiple times before in different ways.
>
> Link to detailed proposal draft:
>
> https://github.com/gabriellanata/swift-evolution/blob/master/proposals/-allow-enumerating-cases-in-enumerations.md
>
> It is currently not possible to enumerate through all the possible cases
> of an enumeration object without adding a hardcoded value or recurring to
> unsafe workarounds. The proposal is to add a method of obtaining an array
> or set of all the possible cases natively for enumerations without
> associated values.
>
> The proposed solution is to implement a native `.cases` static var for
> all enumerations without associated values. This would provide a strict
> type-safe way of enumerating though the possible cases without risking
> runtime errors. The resulting code is a lot cleaner and less prone to
> errors caused by forgetting to update the hardcoded values when modifying
> cases.
>
> Resulting code:
>
>enum PokemonType {
>case Fire, Grass, Water, Wind
>}
>for pokemonType in PokemonType.cases {
>// Do stuff
>}
>PokemonType.cases.count // Returns 4
>
>
> ---
> Gabriel
>
>
> ___
> 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] Shorthand unwrap proposal

[James Campbell via swift-evolution]

Awesome, cheers guys!

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:26, Dmitri Gribenko <griboz...@gmail.com> wrote:

> On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution
> <swift-evolution@swift.org> wrote:
> > So if the function I run inside of the map has a return value of Void
> will
> > that still compile ?
>
> Yes.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shorthand unwrap proposal

[James Campbell via swift-evolution]

So if the function I run inside of the map has a return value of Void will
that still compile ?

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:22, Jordan Rose <jordan_r...@apple.com> wrote:

> I think we’d still just recommend using ‘map’ for this. The reason
> Collection.map and Collection.forEach are different is because we don’t
> promise eager and in-order evaluation for Collection.map. But Optional only
> executes the closure one or zero times, so there’s no ambiguity.
>
> Jordan
>
>
> On Jun 23, 2016, at 09:15, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> So I have a real-life situation in an application, which does what you
> mention:
>
> This code is for a camera app, on a `didSet` it removes a device if set
> from the capture session, and if there is a new one set it adds it to the
> capture session.
>
> The add and remove methods indeed don't take optionals.
>
> So this is the code before:
>
> var audioDevice: AVCaptureDeviceInput? = nil {
>
>
> willSet {
>
> if let audioDevice = audioDevice {
>
>captureSession?.removeInput(audioDevice)
>
> }
>
> }
>
>
> didSet {
>
> if audioDevice = audioDevice {
>
>captureSession?.addInput(audioDevice)
>
> }
>
> }
>
> }
>
>
> and after:
>
> var audioDevice: AVCaptureDeviceInput? = nil {
>
>
> willSet {
>
> audioDevice.unwrap {
>
> self.captureSession?.removeInput($0)
>
> }
>
> }
>
>
> didSet {
>
> audioDevice.unwrap {
>
> self.captureSession?.addInput($0)
>
> }
>
> }
>
> }
>
>
> The last two saved me a lot of typing in these cases and I feel like it is
> more clear what is going on due to the `unwrap` method being clear in it's
> intent and the lack of `audioDevice` being repeated multiple times.
>
> *___*
>
> *James⎥Head of Trolls*
>
> *ja...@supmenow.com <ja...@supmenow.com>⎥supmenow.com
> <http://supmenow.com/>*
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 23 June 2016 at 17:11, Sean Heber <s...@fifthace.com> wrote:
>
>> I’m a bit tore on this myself. I see the appeal, but let’s say we had
>> such a function. If you wanted to use it with an named parameter it’d look
>> like this:
>>
>> myReallyLongOptionalName.unwrap { string in
>>   doSomethingWith(string)
>> }
>>
>> And that is actually *more* characters than the current approach:
>>
>> if let string = myReallyLongOptionalName {
>>   doSomethingWith(string)
>> }
>>
>> However it’d be a big win especially when you can skip $0 and the braces
>> entirely such as:
>>
>> myReallyLongOptionalName.unwrap(doSomethingWith)
>>
>> Of course if we were dealing with methods, you could write this like:
>>
>> myReallyLongOptionalName?.doSomething()
>>
>> And that is probably hard to beat.
>>
>> So I think the problem really only presents itself when you have an
>> optional that you need to unwrap and use as a parameter to something that
>> does not take an optional.
>>
>> I don’t have a solution - just trying to clarify the situation. :)
>>
>> l8r
>> Sean
>>
>>
>> > On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I was wondering if people would be open to adding an unwrap method to
>> the Optional type,  I already have a method like this which shortens code
>> for me.
>> >
>> > So this:
>> >
>> > let myReallyLongOptionalName: String? = "Hey"
>> >
>> > if let string = myReallyLongOptionalName {
>> >   doSomethingWith(string)
>> > }
>> >
>> > Could become"
>> >
>> > let myReallyLongOptionalName: String? = "Hey"
>> >
>> > myReallyLongOptionalName.unwrap {
>> >   doSomethingWith($0)
>> > }
>> >
>> > The block would only be fired if myReallyLongOptionalName has a value.
>> >
>> > ___
>> >
>> > James⎥Head of Trolls
>> >
>> > ja...@supmenow.com⎥supmenow.com
>> >
>> > Sup
>> >
>> > Runway East >
>> >
>> > 10 Finsbury Square
>> >
>> > London
>> >
>> > > EC2A 1AF
>> >
>> > ___
>> > 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] Shorthand unwrap proposal

[James Campbell via swift-evolution]

I was wondering if people would be open to adding an unwrap method to the
Optional type,  I already have a method like this which shortens code for
me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] the "guard" keyword, again

[James Campbell via swift-evolution]

I think unless has always made more sense, guard felt like a multithreaded
statement as in guard this variable from other threads.

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 21 June 2016 at 09:14, Rimantas Liubertas via swift-evolution <
swift-evolution@swift.org> wrote:

>
> In summary, “require … else” is a very clean choice and beats “guard ...
>> else” handily.
>>
>
> For you maybe. I prefer quard—it carries slightly different semantic load
> and fits more cases, imho.
>
> r.
>
> ___
> 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] [Swift 4] Support an official reactive library

[James Campbell via swift-evolution]

With swift 3 around the corner, I wanted to propose some higher level focuses 
for version 4.
My first suggestion is an official reactive library. Reactive programming has 
gained a huge amount of popularity especially with reactive cocoa and rxswift.
Microsofts support of the original Rx library is a big help in this. 
I believe the apple ecosystem would benefit from offering this same support to 
an official library, why?
- RxSwift in particular is pushing the limits of the compiler and often crashes 
source kit. I believe if we had an official library we could have tighter 
feedback to the compiler team.- it would help address the complexities of async 
code without reinventing the wheel.- it could reduce app size. RxSwift is a 
large framework right now but I would imagine with the right system knowledge 
it could be refined and the API simplified with an official library.
Let me know your thoughts
Sent from Supmenow.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[James Campbell via swift-evolution]

That would be handy

Sent from Supmenow.com




On Sat, Apr 30, 2016 at 1:31 PM -0700, "David Sweeris via swift-evolution" 
 wrote:











On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution 
 wrote:
I think this specific proposal asking for compiler magic to auto-unwrap 
invisibly and only in very limited cases, as this proposal suggests, ends up 
breaking a lot more than it fixes. I can only see circumstances of this working 
with variables in the current scope, as anything like a property could be 
updated by other methods, threads etc, and the compiler couldn't be certain of 
state.
I think a language feature like you describe would be a lot more helpful, but 
I'd love to hear others' views on that.
- Rod
Yeah, auto-unwrapping "wherever it might be possible" seems too magical to me. 
I wouldn’t object to the compiler auto-unwraping optionals within a well 
defined code block, though://foo is T?if foo != nil {//foo is T within this set 
of curly braces}But even that invokes a bit of compiler magic, in that for this 
one type of enum (`Optional`), the compiler knows that if it isn’t one case, it 
must be the other. I’d prefer a more general solution…
What if the “is” keyword could function as a kind of incomplete switch?var foo: 
UnicodeDecodingResult...if foo is .Result {    //since we know foo is a result, 
`foo` refers to foo's associated or raw value within this set of curly 
braces}This allows the language feature (and relevant compiler code paths) to 
be used with any enum, not just Optionals. The “optional unwrapping behavior" 
could then be written like this:var bar = 4 as Int?...if bar is .Some {    
//bar is 4 within this set of curly braces}
- Dave Sweeris





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

Re: [swift-evolution] Auto Unwrapping Of Optionals

[James Campbell via swift-evolution]

Wouldn't calling the NSDate constructor escape the context ?

Sent from Supmenow.com




On Fri, Apr 29, 2016 at 1:47 PM -0700, "Tod Cunningham via swift-evolution" 
 wrote:










Adrian, excellent example of a challenging case.  I would say that when calling 
any method that might mutate the value, the compiler would no longer be able to 
safely auto unwrap.  That really limits the usefulness of this capability, at 
least for classes. For classes that would mean any call that would leave the 
current context would disable the auto unwrapping. For structs, it would be any 
mutating method would disable the auto unwrap.

I modified my example a bit to show how this would effect the ability to auto 
unwrap.

class Test {
  var today: NSDate? = nil

  func test() {
 today = today ?? NSDate()
 let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No ! 
required (auto unwrapped)

 // today can no longer be auto unwrapped as calling timeIntervalSinceNow 
has escaped
 // the enclosing context and could cause side effects with this instance.
}

It would be nice if the compiler could know that timeIntervalSinceNow had no 
dependencies or knowledge of class Test, but I doubt that would be practical.

However if Test was a struct the mutation information is readily available, so 
we know these calls would be safe:

struct Test {
var today: NSDate? = nil

mutating func test() {
today = today ?? NSDate()
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow // No ! 
required (auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow // 
Explicit unwrapping would still be allowed
print("Today is \(today)") // Would be printed as a value (not an 
optional)

// today can still be auto unwrapped as it won't be mutated by 
timeIntervalSinceNow or print
}
}


From: > on behalf of Adrian Zubarev via swift-evolution >
Reply-To: Adrian Zubarev >
Date: Friday, April 29, 2016 at 3:21 PM
To: "swift-evolution@swift.org" >
Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals

+1 But your example is too good to be true. :)

What would happen to this code:

class A {

var value: Type? = nil

func reset() { self.value = nil }

func test() {

self.value = self.value ?? Type()

self.reset()

self.value.doSomething()

// can the compiler be sure that our value wasn't reset somewhere from 
a different scope ?
 }
}

I'm curious what will happen here. Can someone clarify on that?

--
Adrian Zubarev

Am 29. April 2016 um 16:37:37, Tod Cunningham via swift-evolution 
(swift-evolution@swift.org) schrieb:

I'm new to the swift evolution community, but I wanted to toss an idea out 
there to get some feedback on it. So here it goes...

Currently, if you assign a non-nil value to an optional and then want to access 
that optional later, in the same context, you need to manually unwrap the 
value. This is usually done either by using "!" or by using something like "if 
let" or guard.

What would it be like if the compiler could auto unwrap, in cases where in 
knows the optional will have some value? This would make the code "clean" and 
still be safe.

This concept of Auto Unwrapping of Optionals is similar to Implicitly Unwrapped 
Optionals, but is only applied when the compiler knows it is safe to do so.

Take the following example:

class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as an optional
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow // Requires ! or 
(if let) to unwrap
// ... do stuff with timeInterval ...
}
}

With the above example, the compiler could known that today has a value after 
it's set in the test method. So why couldn't the compiler auto unwrap it when 
accessed? This would mean manual unwrapping would be unnecessary:

class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No ! required 
(auto unwrapped)
// ... do stuff with timeInterval ...
}
}

If the value later gets set to an optional value, then it will no longer be 
auto unwrapable :

class Test {
var today: NSDate? = nil

func optionalDay() -> NSDate? {
return NSDate()
}

func test() {
today = today ?? NSDate()
print("Today is \(today)") // Would be printed as a value (not an optional)
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No ! required 
(auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow // Explicit 
unwrapping would still be allowed

// If today is assigned an optional value, we can no longer auto unwrap it
today = optionalDay()
print("Today is \(today)") // Would be printed as an optional
let timeInterval3: NSTimeInterval = today!.timeIntervalSinceNow // manual 

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

[James Campbell via swift-evolution]

What if we had a concept similar to errors and try ?

Given this function:

func sort() -> Self {
}

mutating sort() -> Self {
}


If a developer calls:

array.sort()

It will sort a copy of that array, in order to sort in place the developer
must confirm the mutation like so:

mutate array.sort()

This will then call the mutating version of sort :)

*___*

*James⎥Chief Of Fun*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 22 April 2016 at 12:31, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> This is why I mentioned Xcode; while we can have ampersand as a language
> feature for marking such things explicitly (i.e- developer consents to
> doing it), we could also just have Xcode highlight inout parameters and
> mutating methods differently, but would these represent the same explicit
> “I know that what I’m doing here will have side-effects” impact (especially
> if other IDEs add Swift support but don’t do this).
>
> > On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > From one point of view, it will be really awesome if we'll have some
> kind of 'marker' for mutating methods so we can clearly see in code if that
> method changes the instance(just like we all agree that we must specify &
> for inout parameter).
> >
> > From other point of view, this will add a much more noise(and typing) in
> code as we often(in most cases?) use mutating methods. Have a code with a
> huge number of & symbols(or other) in it - not the best thing.
> >
> > I don't see how we can unite both points.
> >
> > On 22.04.2016 10:00, Tyler Cloutier via swift-evolution wrote:
> >> If I recall correctly there was a thread with a similar idea which
> instead
> >> would create a new operator for mutation or a new way of method
> invocation,
> >> such that mutating methods would be called with &. or something
> similar. e.g.
> >>
> >> foo&.add(5)
> >>
> >> I think the consensus was that that was not a particularly familiar
> syntax
> >> and it would add a decent amount of noise.
> >>
> >> There may have also been some issues with the grammar, I can't recall.
> >>
> >> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution
> >> > wrote:
> >>
> >>> Hey
> >>>
> >>> I think adding “&” to methods will reduce the readability of the code.
> >>> Also, keyword “mutating” makes it super clear and readable that my
> method
> >>> is mutating the values.
> >>>
> >>> 1. mutating func add(value: Double){…}
> >>>
> >>> 2. func add&(value: Double){…}
> >>>
> >>> I think it’s easy to skip the information encoded into the 2nd function
> >>> which is this function is mutating a value as compared to 1st. When I
> >>> read 1st function I start reading with keyword “mutating” making its
> >>> intentions clear to me.
> >>>
> >>> Also, it might become a symbol nightmare with following type signature
> of
> >>> a function-
> >>>
> >>> func nightmare&(title: String?) -> String? -> String?{…}
> >>>
> >>> I can see the advantage of using “&” when calling a function. It makes
> >>> clear at the call site that this method is mutating but still I don’t
> >>> find eliminating “mutating” a good step for the reasons mentioned
> above.
> >>>
> >>> Maybe we can think of some better solution.
> >>>
> >>> Thanks
> >>>
> >>> -Krishna
> >>>
>  On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution
>  > wrote:
> 
>  swift-evolution@swift.org 
> >>>
> >>> ___
> >>> 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] Shortcut for creating arrays

[James Campbell via swift-evolution]

Pehaps we could have a function that splits by whitespace.

"h j c k".split()

*___*

*James⎥Alex's Minder*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, you can do this already:
> let words = "rats live on no evil star".componentsSeparatedByString(" ")
> so I don't know how much a shortcut is needed.
>
> And given '%w' would currently be impossible in Swift as an operator
> containing a letter, is there a Swiftier function name or operator for this?
>
> On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hey guys,
>>
>> Very often we need to create an array strings. It's a routine task and I
>> really like shortcut in Ruby that shortcut makes everyday coding a little
>> bit easier and fun:
>>
>>words = %w[rats live on no evil star]
>>
>> What do you think about adding something like this in Swift?
>>
>> Cheers,
>> Arsen
>>
>> ___
>> 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] Generic Alaises

[James Campbell via swift-evolution]

Ross put it better than I ever could :) yes this is what I meant 

Sent from Supmenow.com




On Wed, Apr 6, 2016 at 1:45 PM -0700, "Ross O'Brien" 
<narrativium+sw...@gmail.com> wrote:










It's not the same topic. Let's take an example: suppose we have a data 
structure for a graph of nodes and edges, where the nodes and edges are indexed 
and both have values. So we have a Graph.Now suppose we want a shortest path from one 
node to another, and we have a data structure to represent that. Now we have a 
Path. They 
both have the same 'generic signature'. If you're navigating a Graph<String, 
Int, City, Motorway>, you're going to want a Path<String, Int, City, Motorway> 
as output.
Right now you might write that as:func shortestPath<NodeIndex, EdgeIndex, 
NodeValue, EdgeValue>(graph:Graph<NodeIndex, EdgeIndex, NodeValue, EdgeValue>, 
startNode: NodeIndex, endNode: NodeIndex> -> Path<NodeIndex, EdgeIndex, 
NodeValue, EdgeValue>
It might save a fair amount of typing if we had a generic equivalent to both 
typealias and associatedtype.
associatedgenerics GraphElements = func shortestPath(graph: 
Graph, startNode, 
endNode) -> Path
genericalias NavigationGraphElements = GraphElements<String, Int, City, 
Motorway>
typealias NavigationGraph = Graph// 
navigationGraph.shortestPath() now returns a Path// 
this last part is closest to the proposal under review.

On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution 
<swift-evolution@swift.org> wrote:
Chris Lattner has a proposal under review on this topic. 
milos

On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
<swift-evolution@swift.org> wrote:
This was inspired from the topic about moving where clauses out of parameter 
lists.
Certain generics get very long winded, I was wondering if we could create some 
sort of alias for generics.
func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:
genericalias SequencesWithSameElements<T, U> =  
func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
func ==  (lhs: T, _ rhs: U) -> Bool


___

James⎥

ja...@supmenow.com⎥supmenow.com

Sup

Runway East


10 Finsbury Square

London


EC2A 1AF 

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

[James Campbell via swift-evolution]

This was inspired from the topic about moving where clauses out of
parameter lists.

Certain generics get very long winded, I was wondering if we could create
some sort of alias for generics.

func anyCommonElements 
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:

genericalias SequencesWithSameElements =  

func anyCommonElements  (lhs: T, _ rhs: U) ->
Bool
func ==  (lhs: T, _ rhs: U) -> Bool

*___*

*James⎥*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[James Campbell via swift-evolution]

In these case of module operator conflicts perhaps there could be a way we
could import these operators ?

Likes a #importOperators(OtherModule) or some kind of build flag.

*___*

*James⎥Future Prime Minister*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sun, Apr 3, 2016 at 12:26 PM, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
> I'm wondering whether we can treat operators the way we recently decided
> to treat selectors: if there is an ambiguity, it should be possible not
> just to specify which module they came from, but their fixity or argument
> types. If module D decides that '++' should refer to 'traditional postfix
> number incrementation', and F decides that it should be an infix 'conjoin
> two numbers as a string and turn the result into a number (e.g. 5 ++ 4 ->
> 54)' then a #selector-like operator signature would come in really handy.
>
>
> On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think this is a great suggestion! One potential problem I can see (if I
>> understood this correctly) is that modules are allowed to set up their own
>> precedence rules for operators defined elsewhere. I think this might lead
>> to some difficult to debug errors if a developer of one module (who is used
>> to certain conventions) then has to work with a different, independent
>> module (where the conventions are different). This is one area where
>> numerical precedence weights seem to be superior as they at least refer to
>> a common subjective coordinate system.
>>
>> Maybe one should also have visibility for precedence, for instance having
>> precedence module-internal by default?
>>
>> Best,
>>
>>  — Taras
>>
>> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom
>> operators. I insist that this time we should focus less on linguistic
>> aspects.
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Introduction
>>
>> Replace syntax of operator definition:
>>
>> infix operator <> { precedence 100 associativity left }
>>
>> With a directive:
>>
>> #operator(<>, fixity: infix, associativity: left)
>>
>> Also replace numeric definition of precedence with separate comparative
>> precedence definitions:
>>
>> #precedence(+, lessThan: *)
>> #precedence(+, equalTo: -)
>>
>> Swift-evolution thread: link to the discussion thread for that proposal
>> 
>>
>> 
>> Motivation
>> Problems
>> with numeric definition of precedence
>>
>> In the beginning, operators had nice precedence values: 90, 100, 110,
>> 120, 130, 140, 150, 160.
>>
>> As time went, new and new operators were introduced. Precedence could not
>> be simply changed, as this would be a breaking change. Ranges got
>> precedence 135, as got precedence 132. ?? had precedence greater than <,
>> but less thanas, so it had to be given precedence 131.
>>
>> Now it is not possible to insert any custom operator between < and ??.
>> It is an inevitable consequence of current design: it will be impossible to
>> insert an operator between two existing ones at some point.
>>
>> Problems
>> with a single precedence hierarchy
>>
>> Currently, if an operator wants to define precedence by comparison to one
>> operator, it must do so for all other operators.
>>
>> In many cases, this is not wished. Example: a & b < c is a common error
>> pattern. a / b as Double is another one. C++ compilers sometimes emit
>> warnings on these. Swift does not.
>>
>> The root of the problem is that precedence is defined between all
>> operators. If & had precedence defined only by comparison to other
>> bitwise operators 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[James Campbell via swift-evolution]

What about local for a file only or scope definition ? 

Sent from Supmenow.com




On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" 
 wrote:










Ah, sorry! Those are all clear to me; it's the possibility of writing some 
other module name there that would have the wrong implications.
Jordan
On Mar 30, 2016, at 12:38 , Ross O'Brien  wrote:
Damn, and I thought it was clear all this time that 'private(module)', or 
'private(#module)', or 'moduleprivate', meant that the symbol is visible only 
inside the module. It's always been a suggested replacement specifier for 
'internal'.
On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution 
 wrote:

On Mar 29, 2016, at 17:47 , Brent Royal-Gordon  wrote:
If Scala style access modifiers were adopted for Swift then a private(file) 
modifier would also be necessary to give the current private functionality.

I could imagine having these options:

public  // visible to 
all everyone
private(scope-name, scope-name, …)  // visible to specified scopes 
(plus current scope)
private // visible only 
to current scope

scope-name could perhaps be:

* A type name (or Self, which would mimic C++-style private, or perhaps even 
C++-style protected depending on how we treat inheritance)
* A module name (or #module for the current module)
* A file name string (or #file for the current file)

And then the default would simply be `private(#module)`.

Alternatively, the parameterized level could be given a different name, like 
`internal` or `shared`. If that were the case, then `#module` might simply be 
the default.

I've actually thought about this before (well, at least at the module level) 
and ultimately decided it was a bad idea for it to be part of the access 
control system. Why? Because there's nothing "private" about sharing with 
another module, even if it's just one other module.
- You don't get any secrecy because you have to publish all symbols and 
metadata as public.- You can't optimize based on knowledge of how the 
declaration is used.- Exposing something to another module can be viral, just 
like making something 'public' would be viral: all of a type's protocol 
conformances are exposed, a class's superclass must be exposed, all the types 
in a function signature have to be exposed (or already public).
All of this means that this behaves more like "public" than like "private"; 
it's "public, but not the entire public". The restriction on use sites is an 
artificial one.
Now, it is a very useful feature! Apple, of course, does this all the time with 
its "SPI". But I think the right form of the feature is to be able to tag a 
bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or 
possibly even "limited to module 'X'", and then have a tool to strip them out 
of the swiftmodule file when you're ready to ship this module to people. That 
way you're enforcing your limitations as much as possible, while still using 
the same binaries for both internal and external clients. (Remember that the 
swiftmodule file serves essentially the same purpose as header files in C.)

At the file level, there's nothing inherently wrong with this idea, but I don't 
think there's enough gain to writing file strings directly in source files. 
Pointing to a future "comprehensive submodules model" would be disingenuous 
because that's a huge feature with a lot of subtlety, but I think "just make 
this accessible to one other file" is additional complexity for not much gain. 
It's also subject to slippery-slope: once one file is added, I don't think 
anyone would think too hard about adding a second file, and then…
Jordan
___

swift-evolution mailing list

swift-evolution@swift.org

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










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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[James Campbell via swift-evolution]

* What is your evaluation of the proposal?
I think this is a positive step in the right direction but I think there still 
needs to be more amendments. So a +1 if address the issues I'm about to outline.
Anything not annotated should be imported as an optional not a IUO, this makes 
it safer to handle the nil case with legacy code. 
This is also truer to the intent of the original objective c code.
The proposal so far agrees with this, however there is one part I think could 
make clearer.
This:
Let x: Int! = 5Let y = x 
It's not clear to me that y would be converted to an optional or that it would 
crash if it couldn't be type converted. This is a huge departure from the 
existing swift.
I think it would be better to have what I call Optional Type Confermence.
If I want y to be a Int! I can refer to x with a ! :
Let x:Int! = 5Let y = x!
That way if x is nil the app will trap and this provides a path for existing 
code to still use this behaviour plus it's now obvious that x will be treated 
like an unwrapped optional.
If you wanted x to be treated like an optional you would use ? 
Let x: Int! = 5Let y = x?
This would make the behaviour the proposal is proposing much clearer.   * Is 
the problem being addressed significant enough to warrant a change to 
Swift?Although the proposal doesn't outline a problem, I do believe the 
optional system in swift today isn't safe enough. Indeed I released an app that 
crashed due to swift importing an unannotated piece of objective c code that 
wasn't clear about how it was an IUO and crashed.Anything that improves this 
visibility of IUOs and reduces the need of them I am for.
* Does this proposal fit well with the feel and direction of Swift?This 
fits with Swift 3s simplification of the APIs   * If you have you used other 
languages or libraries with a similar feature, how do you feel that this 
proposal compares to those?I don't have any experience in other languages.  
  * How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

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,

-Chris Lattner
Review Manager



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



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

Re: [swift-evolution] Promote "primitive" types to enums in extensions

[James Campbell via swift-evolution]

I would rather have a syntax that mirrors the way Protocol does it.

struct Card {
suit:enum
value:Int
}

or we could change it so this only excepts the enum itself unless
you explicitly cast from a Int or another enum:

struct Card {
suit:CardSuit
value:Int
}

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez <
swift-evolution@swift.org> wrote:

> It is a common practice in C to assign to integer (int, int16, int64,
> etc.) typed variables “constant" values declared in enums. In swift, it is
> in fact possible to do that by using enums' “rawValue” property. When
> importing structs from C into swift, we even get some fields declared with
> an integer type, but expecting the assignment of a “constant” declared
> inside an enum. Of course, this is error prone, it is “old-style”
> programming and very confusing for newcomers. To solve this issue, my
> proposal is to be able to create extensions that promote certain fields
> within a class or struct to enums.
>
> For instance, let’s take these sample C struct and enum:
>
> struct Card {
> int suit;
> int rank;
> };
>
> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>
> (Note: I understand that above code follows a bad programming practice,
> yet it is widely common)
>
> It should be imported into swift as follows:
>
> struct Card {
> suit:Int
> value:Int
> }
>
> enum CardSuit : Int {
> case Hearts, Diamonds, Clubs, Spades
> }
>
> Now, I propose to be able to create an extension as follows:
>
> extension Card {
> #enumvalue(suit:CardSuit)
> }
>
> From this moment on, the suit field should only receive CardSuit values,
> thus not requiring the use of raw values for assignments.
>
> These extensions should also be of great interest for people using
> CoreData, since it is not possible to declare enums in models. Therefore,
> to declare enums, it is necessary to declare integer values, and then use
> the “unsafe”, “unexpressive" approach explained before.
>
> Note that the proposal intends to only support promotions from integer
> values to enum values, but, for example, it could also be extended to
> string values.
>
> Finally, it could be appropriate to extend this proposal to redeclare
> func’s signatures, in order to promote certain parameters to enum values.
>
> Best,
>
> Carlos.
> ___
> 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] struct subtyping

[James Campbell via swift-evolution]

I was treating this as a Mixin.

So the property from Object is Mixed into Tree and User but it isn't a
Subclass so any comparison between the two isn't possible.

But on reflection you bring up a very valid point.

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 5:34 PM, Tino Heth <2...@gmx.de> wrote:

> struct Object {
> let identifier: String
> }
>
> struct User: Object {
>
> }
>
> struct Tree: Object {
> }
>
> The last two structs get the identifier property "mixed" in but are unique
> types :)
>
>
> Is unique meant so that User-Objects can't be used as "Object"-Object
> parameters?
> I'm asking because this might be the biggest source of confusion with
> struct inheritance:
> As the two "child-structs" don't add new data to their parent, they would
> (technically) be compatible — but this is fragile, so it might be
> preferable to "hide" polymorphism by default, and maybe add an annotation
> to explicitly allow that a sub-struct can be used as its parent type.
> @compatible(Float) struct SpecialFloat: Float...
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Deprecating Trailing Closures

[James Campbell via swift-evolution]

I think the feature should stay but we need community guidelines on when
and when not to use them.

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 4:13 PM, William Dillon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 24, 2016, at 7:18 AM, Kurt Werle via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Coming from ruby, I'm quite fond of trailing closures.  I couldn't really
> give you a concrete reason why - putting them in the ()'s really isn't that
> big a deal.  But I'll say that I move them outside every single time...
>
> I will say that your examples are the most trivial possible and that the
> more complex the closure (describing context variables and return types,
> throws, etc) the uglier it seem to me to put it inside parens.
>
>
> Agree.
>
> Another thing I like about trailing closures is that it allows me to make
> custom constructs that feel more like a part of the language.  For example,
> I really love this extension for NSLock that I have:
>
> extension NSLock {
> func protect(action: (Void) -> Void) {
> self.lock()
> action()
> self.unlock()
> }
> }
>
> Now, whenever I need to use my lock, I can just do:
>
> peersLock.protect {
> outputString += "\(self.peers.count) peers:\n"
> for (_, peer) in self.peers {
> outputString += "\(peer)\n"
> }
> }
>
> To me, it looks cleaner to me to not have this paren dangling around at
> the end.  On this one I’d definitely say that if you don’t like it, don’t
> use it.  I don’t *think* that you’re forced to use it anywhere.  It’s a
> hard sell to take it away from everyone.
>
> - Will
>
> ___
> 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] struct subtyping

[James Campbell via swift-evolution]

Would love a way of extending an existing struct as a new type but it not
being related to the struct it extends.

Sort of like a mixin but for structs, so I could have:

struct Object {
let identifier: String
}

struct User: Object {

}

struct Tree: Object {
}

The last two structs get the identifier property "mixed" in but are unique
types :)

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 2:16 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Could we accomplish something similar to `newtype` by making the
> `typealias` declaration more powerful?
> It's the first thing I tried, but afair someone from the Core Team opposed
> extending typealias - and I had to agree that an "alias" should be just a
> synonym.
> ___
> 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] idea: immutable setters for structs and tuples?

[James Campbell via swift-evolution]

Could we draft up a proposal :)

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Wed, Mar 23, 2016 at 10:49 PM, Rudolf Adamkovic via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for a standardized way of doing this!
>
> R+
>
> Sent from my iPhone
>
> On 23 Mar 2016, at 21:51, Andrey Tarantsov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >> I would very much like a standardized way of doing this.
> >
> > +1 for a function like with/lens in stdlib.
> >
> > A.
> >
> > ___
> > 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] Abolish IUO type

[James Campbell via swift-evolution]

One thing I've had bit me is the lack of some sort of confirmation, see
this example.

I have a objective-c method in a library like so:

- (void)observe:(CallbackBlock)block;

The CallbackBlock is a type def-ed block like so:

typedef void (^CallbackBlock)(FDataSnapshot *snapshot);

The parameter in the block gets converted into a IUO, I ended up releasing
an app that crashed due to that IUO being nil.

The code that crashed was something like this

object.observe {
$0.doSomething()
}

There is no way to tell that the $0 was a IUO. The compiler didn't force me
to confirm in it in some way using a ! and unless I remembered to check the
header I would have a crash.

How would this work under your proposal ?

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Fri, Mar 18, 2016 at 6:53 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > (Come to think of it, is there a cost to converting between `T?` and
> `T!`, or do they get optimized into the same thing?)
>
> I can't imagine there would be. @autounwrapped (or whatever) is a purely
> compile-time thing which tells the compiler to automatically insert a `!`
> operator if it will make the expression typecheck. Other than that
> compile-time behavior, `!` is an exact synonym for `?`.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Potential Bug with Compiler in 2.1.1 and UnitTests

[James Campbell via swift-evolution]

I have a class that specifies a initialiser taking any class that
implements the protocol "ChatDatastore"

I can use this fine in the functions for my test cases.

However if I try to initialise it in a member either statically, lazily or
even via a computed variable it shows an error stating "Instance member
'chatDatastore' cannot be used on type 'ChatSessionRowViewModelTests'

Not only is this confusing its plain wrong. I am passing in a Mock which
implements this protocol for the purposes of testing.

This should work yet it seems to think that the initializer takes a totally
different type than specified in the code. It should accept my Mock class
since it implements this protocol yet it complains that I need to give it
an instance of my testing class. Which makes no sense :S

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Abolish IUO type

[James Campbell via swift-evolution]

One thing I've had bit me is the lack of some sort of confirmation, see
this example.

I have a objective-c method in a library like so:

- (void)observe:(CallbackBlock)block;

The CallbackBlock is a type def-ed block like so:

typedef void (^CallbackBlock)(FDataSnapshot *snapshot);

The parameter in the block gets converted into a IUO, I ended up releasing
an app that crashed due to that IUO being nil.

The code that crashed was something like this

object.observe {
$0.doSomething()
}

There is no way to tell that the $0 was a IUO. The compiler didn't force me
to confirm in it in some way using a ! and unless I remembered to check the
header I would have a crash.

How would this work under your proposal ?

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Wed, Mar 16, 2016 at 5:03 AM, Chris Willmore via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi, swift-evolution,
>
> Some colleagues and I have been working on a proposal
> 
>  to
> remove the ImplicitlyUnwrappedOptional type from Swift and replace it with
> an IUO decl attribute. Please have a look; I would greatly appreciate any
> comments you have before I push this proposal forward.
>
>
> https://github.com/cwillmor/swift-evolution/blob/master/proposals/-abolish-iuo.md
>
> Thanks,
> — Chris Willmore
>
>
> Abolish ImplicitlyUnwrappedOptional type
>
>- Proposal: SE-
>- Author: Chris Willmore 
>- Status: TBD
>- Review Manager: TBD
>
> This proposal seeks to remove the ImplicitlyUnwrappedOptional type from
> the Swift type system and replace it with an IUO attribute on declarations.
> Appending ! to the type of a Swift declaration will give it optional type
> and annotate the declaration with an attribute stating that it (or, in the
> case of a function, the return value of its application) may be implicitly
> unwrapped.
>
> 
> Motivation
>
> The ImplicitlyUnwrappedOptional ("IUO") type is a valuable tool for
> importing Objective-C APIs where the nullability of a parameter or return
> type is unspecified. It also represents a convenient mechanism for working
> through definite initialization problems in initializers. However, IUOs are
> a transitional technology; they represent an easy way to work around
> un-annotated APIs, or the lack of language features that could more
> elegantly handle certain patterns of code. As such, we would like to limit
> their usage moving forward, and introduce more specific language features
> to take their place. Except for a few specific scenarios, optionals are
> always the safer bet, and we’d like to encourage people to use them instead
> of IUOs.
>
> This proposal seeks to limit the adoption of IUOs to places where they are
> actually required, and put the Swift language on the path to removing
> implicitly unwrapped optionals from the system entirely when other
> technologies render them unnecessary. It also completely abolishes any
> notion of IUOs below the type-checker level of the compiler, which will
> substantially simplify the compiler implementation.
>
> Proposed
> solution
>
> I propose demoting implicitly unwrapped optionals from being a first-class
> type in the Swift type system to being an attribute on declarations in
> Swift. This attribute will be allowed in the following locations:
>
>- property and variable declarations
>- initializer declarations
>- function declarations
>
> Declarations that are marked with the IUO attribute must have optional
> type. A reference to a variable or property with the IUO attribute may be
> implicitly forced (i.e. converted to the underlying type) when being
> type-checked, thus replicating the current behavior of a declaration with
> IUO type. Likewise, the result of a function application or initialization
> where the callee is a reference to a function declaration with the IUO
> attribute may be implicitly forced.
>
> The appearance of ! at the end of a property or variable type no longer
> indicates that the property or variable has IUO type; rather, it indicates
> that (1) the declaration has optional type, and (2) the declaration has the
> IUO attribute. The appearance of ! at the end of the return type of a
> function indicates that the function has optional return type and the IUO
> attribute. The use of init! in an initializer declaration indicates that
> the initializer is failable and has the IUO attribute.
>
> Because there is no longer an IUO type, types with nested IUOs 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[James Campbell via swift-evolution]

Just wondering, wouldn't private be enougth for a class level declaration ?

Not sure why we need a file baed one.

*___*

*James⎥Head of Trolls*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Mar 15, 2016 at 12:18 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Per Doug’s email, the core team agrees we should make a change here, but
> would like some bikeshedding to happen on the replacement name for private.
>
> To summarize the place we’d like to end up:
>
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> symbol visible within the current declaration (class,
> extension, etc).
>
> The rationale here is that this aligns Swift with common art seen in other
> languages, and that many people using private today don’t *want* visibility
> out of their current declaration.  It also encourages “extension oriented
> programming”, at least it will when some of the other restrictions on
> extensions are lifted.  We discussed dropping the third one entirely, but
> think it *is* a useful and important level of access control, and when/if
> we ever get the ability to write unit tests inside of the file that defines
> the functionality, they will be a nicer solution to @testable.
>
> The thing we need to know is what the spelling should be for the third
> one.  Off hand, perhaps:
>
> fileprivate
> private(file)
> internal(file)
> fileaccessible
> etc
>
> Some other thoughts on the choice:
> - this will be a declaration modifier, so it will not “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a
> googlable keyword.
>
> Thoughts appreciated.
>
> -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] Explicity Size Clipping

[James Campbell via swift-evolution]

I have a overloaded method for a protocol that takes an Int or double.

I have an issue with swift calling the Int version when passing in a UInt32
. Ideally I would prefer the compiler to detect I am about to do something
which will cause an overflow and throw an error.

I would then have to explicitly add a overloaded UInt32 method or
explicitly convert it to Int like so "Int(uintVariable)".

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] removeFirst, optional equiviliant

[James Campbell via swift-evolution]

What I mean't is it would be great is if it was a native swift error :) so
we could use try? syntax.

On Wed, Jan 6, 2016 at 6:32 PM, Max Moiseev <mois...@apple.com> wrote:

> Hi James,
>
> I believe this code
> <https://github.com/apple/swift/blob/master/stdlib/public/core/RangeReplaceableCollectionType.swift#L235>
>  already
> handles empty array scenario by failing if the precondition is not met.
> Or do you have something else in mind?
>
> max
>
> On Jan 6, 2016, at 9:36 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If you call removeFirst and the array is empty it would be great if it was
> optional so it could return nil or at least it threw an error so you could
> handle that case.
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] STDLibs

[James Campbell via swift-evolution]

Chris do you think there is scope for this ?

On Wed, Jan 6, 2016 at 2:38 PM, Trent Nadeau <tanad...@gmail.com> wrote:

> Big +1 from me. Rust's docs do this well too across trait implementations.
>
> On Wed, Jan 6, 2016 at 5:43 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Is there a way of improving the documentation and hosting it on Swift
>> instead of Apple ?
>>
>> Currently the Array page lists all of the things the class directly
>> implements but doesn't include any of the methods mixed in by protocol
>> extensions (i.e all of the methods from CollectionType).
>>
>> With YardDoc for Ruby it does this, so you know exactly what methods a
>> class has.
>>
>> This confused me to no end as some topics here suggest adding ways of
>> dropping the first X elements and even I have implemented `shift` which I
>> didn't know already exist albeit under another name.
>>
>> Would be great if we could improve these documents for the language in an
>> open source way :)
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] STDLibs

[James Campbell via swift-evolution]

I did but it redirects elsewhere now :S

On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun <er...@ericasadun.com> wrote:

> Have you stopped by swiftdoc.org <http://swiftdocs.org> recently?
>
> :)
>
> -- Erica
>
>
> On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is there a way of improving the documentation and hosting it on Swift
> instead of Apple ?
>
> Currently the Array page lists all of the things the class directly
> implements but doesn't include any of the methods mixed in by protocol
> extensions (i.e all of the methods from CollectionType).
>
> With YardDoc for Ruby it does this, so you know exactly what methods a
> class has.
>
> This confused me to no end as some topics here suggest adding ways of
> dropping the first X elements and even I have implemented `shift` which I
> didn't know already exist albeit under another name.
>
> Would be great if we could improve these documents for the language in an
> open source way :)
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Explicity Size Clipping

[James Campbell via swift-evolution]

This is the full code:

//

//  Box.swift

//  Project

//

//  Created by James Campbell on 06/01/2016.

//

//

// This File implements the Box protocol for Type Safe Alogrithm Types and
other useful things.


import Foundation


//MARK:- Box


protocol Box: CustomStringConvertible, CustomDebugStringConvertible {



typealias FloatLiteralType = Double

typealias IntegerLiteralType = Int

typealias BoxType = Any



var value: BoxType { get set }



init()

init(_ value: BoxType)

}


extension Box where BoxType: CustomStringConvertible {



var description: String {

return self.value.description

}



var debugDescription: String {

return "\(self.value.description)"

}

}


//MARK: FloatingPointBox


protocol FloatingPointBox: Box, FloatLiteralConvertible,
IntegerLiteralConvertible {



typealias BoxType = Double

typealias FloatLiteralConvertible = Double

typealias IntegerLiteralConvertible = Int

}


extension Box where Self.BoxType == Double {



init(_ value: Double) {



self.init()

self.value = value

}



init(_ value: Int) {

self.init()

self.value = Double(value)

}



init(_ value: UInt32) {

self.init()

self.value = Double(value)

}

}


extension FloatLiteralType {



init(_ box: T) {

self.init(box.value)

}



init(_ box: T) {

self.init(box.value)

}

}


extension CGFloat {



init(_ box: T) {

self.init(box.value)

}



init(_ box: T) {

self.init(box.value)

}

}


//Adding FloatLiteralConvertible, IntegerLiteralConvertible


extension FloatingPointBox where Self.BoxType == Double,
Self.FloatLiteralConvertible
== Double {



init(floatLiteral value: Double) {

self.init(value)

}



init(integerLiteral value: Int) {

self.init(value)

}



init(_ value: T) {

self.init(value)

}

}


//

//  Angles.swift

//  Sup

//

//  Created by James Campbell on 22/12/2015.

//  Copyright © 2015 Sup. All rights reserved.

//

// This File defines representations of Degrees and Radians as Type Safe
Alogrithm Types


import Foundation


//MARK:- Degree


struct Degree: FloatingPointBox {



var value: Double = 0



init()

{

}

}


protocol DegreeConvertiable {



init(degreeLiteral value: Degree)

}


extension Degree: RadianConvertiable {



init(radianLiteral value: Radian) {

self.value = Double(value) * 180.0 / M_PI

}



init(_ value: Radian) {

self.init(radianLiteral: value)

}

}


//MARK:- Radian


struct Radian: FloatingPointBox {



var value: Double = 0



init()

{

}

}


protocol RadianConvertiable {



init(radianLiteral value: Radian)

}


extension Radian: DegreeConvertiable {



init(degreeLiteral value: Degree) {

self.value = Double(value) * M_PI / 180.0

}



init(_ value: Degree) {

self.init(degreeLiteral: value)

}

}

let someOptiona: Degreee? = nil

 let degree = someOptional ?? Degree(arc4random_uniform(360))

On Wed, Jan 6, 2016 at 6:57 PM, Félix Cloutier <felix...@yahoo.ca> wrote:

> I either don't understand or can't reproduce the issue. This code:
>
> class Box {
> let value: Int
> init(value: Int) {
> self.value = value
> }
> }
>
> let test: UInt32 = 4
> let box = Box(value: test)
>
>
> does not compile ("foo.swift:10:22: error: cannot convert value of type
> 'UInt32' to expected argument type 'Int'").
>
> Félix
>
> Le 6 janv. 2016 à 13:17:03, James Campbell <ja...@supmenow.com> a écrit :
>
> protocol Box: CustomStringConvertible, CustomDebugStringConvertible {
>
>
> typealias FloatLiteralType = Double
>
> typealias IntegerLiteralType = Int
>
> typealias BoxType = Any
>
>
> var value: BoxType { get set }
>
>
> init()
>
> init(_ value: BoxType)
>
> }
>
> extension Box where Self.BoxType == Double {
>
>
> init(_ value: Double) {
>
>
> self.init()
>
> self.value = value
>
> }
>
>
> init(_ value: Int) {
>
> self.init()
>
> self.value = Double(value)
>
> }
>
>
> init(_ value: UInt32) {
>
> self.init()
>
> self.value = Double(value)
>
> }
>
> }
>
>
>
> Without that last method, Swift tries to give the UInt32 to the Int
> version of the method which isn't safe in my eyes and I would have expected
> a compiler error.
>
> On Wed, Jan 6, 2016 at 6:14 PM, Félix Cloutier <felix...@yahoo.ca> wrote:
>
>> I don't understand. Can you show a code example?
>>
>> Félix
>>
>> Le 6 janv. 2016 à 13:02:43, James Campbell via swift-evo

Re: [swift-evolution] removeFirst, optional equiviliant

[James Campbell via swift-evolution]

I personally would love to have it as optional behaviour. Not sure when you
would ever need it to be non optional ?

On Wed, Jan 6, 2016 at 6:54 PM, Max Moiseev <mois...@apple.com> wrote:

> Ahhh, right.
>
> I believe the thinking here is that since this is an avoidable error, it
> should be handled in the client code with an `if !array.isEmpty { … }`),
> leaving errors to really exceptional and unexpected conditions.
> Using optional here will serve the same purpose, IMHO, but instead of
> preventing the condition, one would have to react to the consequences
> later. Moreover the type will now be Optional and it would also be
> really tempting to write something like `array.removeFirst()!` and have the
> same trapping behavior.
>
> Dave, Dmitri, please correct me if I’m wrong.
>
> max
>
> On Jan 6, 2016, at 10:34 AM, James Campbell <ja...@supmenow.com> wrote:
>
> What I mean't is it would be great is if it was a native swift error :) so
> we could use try? syntax.
>
> On Wed, Jan 6, 2016 at 6:32 PM, Max Moiseev <mois...@apple.com> wrote:
>
>> Hi James,
>>
>> I believe this code
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/RangeReplaceableCollectionType.swift#L235>
>>  already
>> handles empty array scenario by failing if the precondition is not met.
>> Or do you have something else in mind?
>>
>> max
>>
>> On Jan 6, 2016, at 9:36 AM, James Campbell via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> If you call removeFirst and the array is empty it would be great if it
>> was optional so it could return nil or at least it threw an error so you
>> could handle that case.
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Explicity Size Clipping

[James Campbell via swift-evolution]

e: Int
>> init(value: Int) {
>> self.value = value
>> }
>> }
>>
>> let test: UInt32 = 4
>> let box = Box(value: test)
>>
>>
>> does not compile ("foo.swift:10:22: error: cannot convert value of type
>> 'UInt32' to expected argument type 'Int'").
>>
>> Félix
>>
>> Le 6 janv. 2016 à 13:17:03, James Campbell <ja...@supmenow.com> a écrit :
>>
>> protocol Box: CustomStringConvertible, CustomDebugStringConvertible {
>>
>>
>> typealias FloatLiteralType = Double
>>
>> typealias IntegerLiteralType = Int
>>
>> typealias BoxType = Any
>>
>>
>> var value: BoxType { get set }
>>
>>
>> init()
>>
>> init(_ value: BoxType)
>>
>> }
>>
>> extension Box where Self.BoxType == Double {
>>
>>
>> init(_ value: Double) {
>>
>>
>> self.init()
>>
>> self.value = value
>>
>> }
>>
>>
>> init(_ value: Int) {
>>
>> self.init()
>>
>> self.value = Double(value)
>>
>> }
>>
>>
>> init(_ value: UInt32) {
>>
>> self.init()
>>
>> self.value = Double(value)
>>
>> }
>>
>> }
>>
>>
>>
>> Without that last method, Swift tries to give the UInt32 to the Int
>> version of the method which isn't safe in my eyes and I would have expected
>> a compiler error.
>>
>> On Wed, Jan 6, 2016 at 6:14 PM, Félix Cloutier <felix...@yahoo.ca> wrote:
>>
>>> I don't understand. Can you show a code example?
>>>
>>> Félix
>>>
>>> Le 6 janv. 2016 à 13:02:43, James Campbell via swift-evolution <
>>> swift-evolution@swift.org> a écrit :
>>>
>>> I have a overloaded method for a protocol that takes an Int or double.
>>>
>>> I have an issue with swift calling the Int version when passing in a
>>> UInt32 . Ideally I would prefer the compiler to detect I am about to do
>>> something which will cause an overflow and throw an error.
>>>
>>> I would then have to explicitly add a overloaded UInt32 method or
>>> explicitly convert it to Int like so "Int(uintVariable)".
>>>
>>> --
>>>  Wizard
>>> ja...@supmenow.com
>>> +44 7523 279 698
>>>  ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>>
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] removeFirst, optional equiviliant

[James Campbell via swift-evolution]

If you call removeFirst and the array is empty it would be great if it was
optional so it could return nil or at least it threw an error so you could
handle that case.

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for newtype feature/typesafe calculations

[James Campbell via swift-evolution]

I've managed to implement this already in the language with a few ugly
corners due to the lack of generic protocols.

I created a protocol based on Box (https://github.com/robrix/Box/) which
works really well. I have extended this to handle certain special protocols
like Equatable so you can do SpecialType == SpecialType, and even
literalConversion.

There is however a lot of boilerplate:

- You have to declare all of your Convertible protocols for converting from
one type to another
- You have to define an empty init so the protocol extensions have
something to chain to.
- You need to write the value property with type.

Due to the lack of protocol generics, you also need to have a protocol for
every type you wish to box which sets the associated type. Of course I
could have done this with classes but I wanted to keep this as a value type
:).

With member-wise initializations and generic protocols this could be
achievable just by adding a Box protocol to the standard library.

Here is my implementation of Box as a protocol:

*protocol Box: CustomStringConvertible, CustomDebugStringConvertible {*



*typealias FloatLiteralType = Double*

*typealias IntegerLiteralType = Int*

*typealias BoxType = Any*



*var value: BoxType { get set }*



*init()*

*init(_ value: BoxType)*

*}*


*extension Box where BoxType: CustomStringConvertible {*



*var description: String {*

*return self.value.description*

*}*



*var debugDescription: String {*

*return "\(self.value.description)㎭"*

*}*

*}*


*//MARK: FloatingPointBox*


*protocol FloatingPointBox: Box, FloatLiteralConvertible,
IntegerLiteralConvertible {*



*typealias BoxType = Double*

*typealias FloatLiteralConvertible = Double*

*typealias IntegerLiteralConvertible = Int*

*}*


*extension Box where Self.BoxType == Double {*



*init(_ value: Double) {*



*self.init()*

*self.value = value*

*}*



*init(_ value: Int) {*



*self.init()*

*self.value = Double(value)*

*}*

*}*


*extension FloatLiteralType {*



*init(_ box: T) {*

*self.init(box.value)*

*}*



*init(_ box: T) {*

*self.init(box.value)*

*}*

*}*


*extension CGFloat {*



*init(_ box: T) {*

*self.init(box.value)*

*}*



*init(_ box: T) {*

*self.init(box.value)*

*}*

*}*


*//Adding FloatLiteralConvertible, IntegerLiteralConvertible*


*extension FloatingPointBox where Self.BoxType == Double,
Self.FloatLiteralConvertible == Double {*



*init(floatLiteral value: Double) {*

*self.init(value)*

*}*



*init(integerLiteral value: Int) {*

*self.init(value)*

*}*



*init(_ value: T) {*

*self.init(value)*

*}*

*}*

Here is my example of using the Box protocol:

*struct Degree: FloatingPointBox {*



*var value: Double = 0*



*init()*

*{*

*}*

*}*


*protocol DegreeConvertiable {*



*init(degreeLiteral value: Degree)*

*}*


*extension Degree: RadianConvertiable {*



*init(radianLiteral value: Radian) {*

*self.value = Double(value) * 180.0 / M_PI*

*}*



*init(_ value: Radian) {*

*self.init(radianLiteral: value)*

*}*

*}*

On Tue, Jan 5, 2016 at 5:24 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 5, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via
> swift-evolution :
> >>
> >> The ideal would be for the compiler to pretend Euros or RefTablePk are
> different types, yet use their parent type at the binary level. This needs
> a specific syntax to teach the compiler which existing methods/operations
> are allowed on the new fake types and which aren’t. These new distinct
> types would *borrow* previous implementations.
> >
> > What about citing the relevant protocols in the newtype definition? This
> should include the ability to use my own protocols to which I have made the
> underlying type conform to by an extension.
>
> This is how my forwarding proposal works.  The newtype syntax I suggested
> as a possible extension looks like this:
>
> newtype Euro = Double forwarding Addable, Subtractable
>
> The keyword could be different, but I think `forwarding` is not bad.  When
> I complete the second draft I think it will make even more sense.  The
> forwarding facility has features to handle non-trivial cases (Self and
> associated type requirements, etc).
>
> >
> > Throwing some syntax into the discussion:
> >
> > newtype Euro = Double : Addable, Subtractable
> >
> > where I have defined the protocols Addable and Subtractable somewhere
> and made Double conform to them if all this is not provided by the standard
> library.
> > The implementation of Euro then borrows the implementation of Double for
> these protocols.
> >

Re: [swift-evolution] removeFirst, optional equiviliant

[James Campbell via swift-evolution]

Yeah I was using this for a LIFO type system :) glad to know there is a
method for this.

On Thu, Jan 7, 2016 at 12:09 AM, Dave Abrahams  wrote:

>
> On Jan 6, 2016, at 3:48 PM, Jacob Bandes-Storch 
> wrote:
>
> Whoops, I meant append()/popFirst. That is, even for a single-ended queue,
> you'll use one "first" operation (less efficient) and one "last" operation.
>
>
> No, a single-ended queue is a stack.  You can use append and popLast on
> Array for that.
>
>
> On Wed, Jan 6, 2016 at 3:47 PM, Dave Abrahams  wrote:
>
>>
>> On Jan 6, 2016, at 3:42 PM, Jacob Bandes-Storch 
>> wrote:
>>
>> Oops, I forgot this existed.
>>
>> I'm assuming you're recommending popLast for performance reasons?
>> Unfortunately, for a
>>
>>
>> …double-ended…
>>
>> queue, you'll need either insertAtIndex(0)/popLast or append()/popLast
>> (or a different data structure)…
>>
>>
>> Yes, the standard library should acquire a Deque data structure at some
>> point.
>>
>
> Is there a SR for this?
>
>
> Not that I know of; have at it!
>
> -Dave
>
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SignedNumberType

[James Campbell via swift-evolution]

What is the purpose of this type ? Why don't we have

UnsignedNumberType

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Improve Number Type

[James Campbell via swift-evolution]

There is a number of deficiencies with Swift and Numbers. Especially when
trying to be clever with generics.

- The API exposes built in types like`BuiltIn.Word` as the return type of
some APIs but there is no way to use said types.
- We have a Float and a Float80. Float and Doubles can't be initialised
(via init) with anything but Integer values but Float80 can be initialized
with both Floating Point and Integer
- We have a SignedNumberType but no UnsignedNumberType, All the floating
points use this protocol, so shouldn't this be NumberType ?
- SignedIntegerType and UnsignedIntegerType have a way of generically
constructing an Int as long as you cast it to the Maximum Int or UInt. But
there is no such thing for Floating Point Numbers.
- We have Float80 and a typealised Float32 and Float64. Why couldn't  have
triple as an extra type name, as having one true type with a number is
confusing ?
- If all number types could be initilized with all number types, then a lot
of the constructors could be in the NumberType protocol.

Just in general it was hard to extend integers and floating point types.
For example in my code I wanted to pass a struct that contained a value to
any Floating Point or Integer and it would convert.

This is what I had to do, which is far too much and even sure I'm not
convinced it will work in every condition.

*protocol Box: CustomStringConvertible, CustomDebugStringConvertible {*



*typealias BoxType = Any*



*var value: BoxType { get set }*



*init()*

*init(_ value: BoxType)*

*}*


*protocol AngleType: Box {*

*typealias BoxType = Double*

*}*

*//Mark:- Box - FloatingPointType Conversion*


*extension SignedIntegerType {*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(IntMax(value.value))*

*}*

*}*


*extension UnsignedIntegerType {*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*



*init(_ value: T) {*

*self.init(UIntMax(value.value))*

*}*

*}*


*extension Float*

*{*

*init(_ value: T)*

*{*

*self.value = value.value.value*

*}*

*}*


*extension Double*

*{*

*init(_ value: T)*

*{*

*self.value = value.value.value*

*}*

*}*


*extension Float80*

*{*

*init(_ value: T)*

*{*

*self.init(value.value)*

*}*

*}*


*extension FloatingPointType {*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*



*init(_ value: T) {*

*self.init(value.value)*

*}*

*}*

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___

[swift-evolution] Default lazy constructor

[James Campbell via swift-evolution]

When creating a lazy variable, maybe we should allow for default closures,
i.e

lazy var userSession: UserSession

Which will construct that object for you
instead of having to do:

lazy var object: MyObject {

let userSession = UserSession()

return userSession

}()

If the initializer requires parameter values then as an extension of this
we could pass them in psuedo C++ style:

lazy var object: UserSession(otherVariable)

Potentially otherVariable in this case could be lazily processed, so that
its the equivalent of:

lazy var object: MyObject {

let userSession = UserSession(otherVariable)

return userSession

}()

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

Thats a small but huge improvement :)

On Tue, Jan 5, 2016 at 6:58 PM, Chris Lattner <clatt...@apple.com> wrote:

> You’re completely right, but we don’t need to change the swift language to
> fix that.  As of 3f19714, which I just pushed, we now emit this error
> message (which includes a fixit hint to insert the colon):
>
> t.swift:2:33: error: use [:] to get an empty dictionary literal
> var distanceCache: [Int: Int] = []
> ^
>  :
>
> instead of:
>
> t.swift:2:33: error: contextual type '[Int : Int]' cannot be used with
> array literal
> var distanceCache: [Int: Int] = []
> ^~
>
> That should address the problem, thanks for pointing this out!
>
> -Chris
>
> On Jan 5, 2016, at 4:51 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The problem for me is that is so counter intuitive I didn't even know you
> could do that.
>
> On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira <
> jeremy.j.pere...@googlemail.com> wrote:
>
>> I don’t understand what the problem is
>>
>> > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > See this code:
>> > var distanceCache: [Int: Int] = Dictionary<Int, Int>()
>> >
>> > It is very long and tedious to write especially if what I am storing
>> changes.
>> >
>> > I propose we be allowed to do the following:
>> > var distanceCache: [Int: Int] = []
>>
>> You can do
>>
>> var distanceCache: [Int: Int] = [:]
>>
>> Also
>>
>> var distanceCache2 = [Int: Int]()
>>
>>
>> > Perhaps this dictionary syntax is just confusing and it was a bad idea
>> to make it the same as an array. Most languages use "{" so why did swift
>> choose to share "[" with arrays and dictionaries.
>>
>> It’s not the same, you need the colons inside. I imagine that braces were
>> discarded on the grounds that it would confuse the compiler with respect to
>> closures, for example
>>
>> var myClosure = {} // is a variable of type () -> ()
>>
>>
>> >
>> > --
>> >  Wizard
>> > ja...@supmenow.com
>> > +44 7523 279 698
>> >  ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

Perhaps instead of "auto" we could allow "lazy" to create a default lazy
constructor for these cases ?

On Tue, Jan 5, 2016 at 12:39 PM, James Campbell  wrote:

> See this code:
>
> var distanceCache: [Int: Int] = Dictionary()
> It is very long and tedious to write especially if what I am storing
> changes.
>
> I propose we be allowed to do the following:
>
> *var distanceCache: [Int: Int] = []*
>
> If this isn't possible then I wouldn't mind having some way of telling the
> compiler to auto create it like so:
>
> *var distanceCache: [Int: Int] ()*
>
> or
>
> *var distanceCache: [Int: Int] = new Dictionary*
>
> or even:
>
> *var distanceCache: [Int: Int] = auto*
>
> *auto var distanceCache: [Int: Int]*
>
> (auto short for auto create)
>
>
> Perhaps this dictionary syntax is just confusing and it was a bad idea to
> make it the same as an array. Most languages use "{" so why did swift
> choose to share "[" with arrays and dictionaries.
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

See this code:

var distanceCache: [Int: Int] = Dictionary()
It is very long and tedious to write especially if what I am storing
changes.

I propose we be allowed to do the following:

*var distanceCache: [Int: Int] = []*

If this isn't possible then I wouldn't mind having some way of telling the
compiler to auto create it like so:

*var distanceCache: [Int: Int] ()*

or

*var distanceCache: [Int: Int] = new Dictionary*

or even:

*var distanceCache: [Int: Int] = auto*

*auto var distanceCache: [Int: Int]*

(auto short for auto create)


Perhaps this dictionary syntax is just confusing and it was a bad idea to
make it the same as an array. Most languages use "{" so why did swift
choose to share "[" with arrays and dictionaries.
-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

[James Campbell via swift-evolution]

The problem for me is that is so counter intuitive I didn't even know you
could do that.

On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira <
jeremy.j.pere...@googlemail.com> wrote:

> I don’t understand what the problem is
>
> > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > See this code:
> > var distanceCache: [Int: Int] = Dictionary<Int, Int>()
> >
> > It is very long and tedious to write especially if what I am storing
> changes.
> >
> > I propose we be allowed to do the following:
> > var distanceCache: [Int: Int] = []
>
> You can do
>
> var distanceCache: [Int: Int] = [:]
>
> Also
>
> var distanceCache2 = [Int: Int]()
>
>
> > Perhaps this dictionary syntax is just confusing and it was a bad idea
> to make it the same as an array. Most languages use "{" so why did swift
> choose to share "[" with arrays and dictionaries.
>
> It’s not the same, you need the colons inside. I imagine that braces were
> discarded on the grounds that it would confuse the compiler with respect to
> closures, for example
>
> var myClosure = {} // is a variable of type () -> ()
>
>
> >
> > --
> >  Wizard
> > ja...@supmenow.com
> > +44 7523 279 698
> >  ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Then Support

[James Campbell via swift-evolution]

I was wondering if this should be part of the stdlib

https://cocoapods.org/pods/Then

-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Then Support

[James Campbell via swift-evolution]

Cheers Erica. I'll try this again but do it properly this time ;)

On Mon, Jan 4, 2016 at 3:24 PM, Erica Sadun <er...@ericasadun.com> wrote:

> This idea probably deserves more attention than it's going to get with
> this pitch for two reasons:
>
> First, the Swift-Evolution list is heavily trafficked and you've given no
> context in either your subject line or your message about what "then" is
> and why it would be valuable to the Swift programming language. It is a
> Cocoapod that introduces "syntactic sugar for Swift initializers", that is
> extended initialization steps to support Cocoa set-up beyond the
> Apple-supplied inits. This is the same $0-delimited approach that has
> evolved spontaneously from a variety of developers.
>
> Second, similar ideas have already been pitched and discussed on-list
> under the topics of method cascading, extended initialization, and so
> forth. You can search the Swift Evolution Archies on
>
>
>- Google (use site:https://lists.swift.org/pipermail/swift-evolution/ in
>your search, e.g.
>
> https://www.google.com/?gws_rd=ssl#q=cascad+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F
>
> <https://www.google.com/?gws_rd=ssl#q=cascad+site:https://lists.swift.org/pipermail/swift-evolution/>
>) or
>- gmane (e.g.
>
> http://search.gmane.org/?query=cascad==gmane.comp.lang.swift.evolution=relevance=and=Zcascad=Gcomp.lang.swift.evolution---A
>)
>
>
> A proposal on adding Dart-like cascades with Swifter-syntax stalled. Old
> proposal here: https://gist.github.com/erica/eb32feb22ba99629285a Bug
> report here: https://bugs.swift.org/browse/SR-160
>
> The topic appears to be a popular one and well liked. I understand its
> best timeframe for discussion will be in about a year as it is unlikely to
> be addressed in Swift 3.0, although you should probably ask an Apple team
> member rather than a general bystander like myself.
>
> Best regards, -- Erica
>
>
> On Jan 4, 2016, at 6:58 AM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was wondering if this should be part of the stdlib
>
> https://cocoapods.org/pods/Then
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[James Campbell via swift-evolution]

This is a relevant article 
https://www.mikeash.com/pyblog/friday-qa-2015-12-25-swifty-targetaction.html?utm_campaign=iOS%2BDev%2BWeekly_medium=email_source=iOS_Dev_Weekly_Issue_231

For this topic

Sent from my iPhone

> On 31 Dec 2015, at 01:33, James Campbell  wrote:
> 
> Good point. Not sure if that's replaceable via a protocol or if that Api is 
> just not suited for swift. 
> 
> There is a proposal somewhere to be able to reference swift methods via back 
> ticks a sort of selector for swift so maybe in this case we would use that.
> 
> Sent from my iPhone
> 
>> On 30 Dec 2015, at 20:27, Tino Heth <2...@gmx.de> wrote:
>> 
>> 
>>> I'm not as familiar with OS X but why is it vital there ?
>> 
>>> Do you have an example of use ?
>> 
>> If those questions are for me ;-):
>> Afair (have to do iOS most of the time now), "Undo" is the most prominent 
>> example. You don't link those menu entries to a concrete object, but rather 
>> say "bind this to a selector whose name is…", and then the system can 
>> determine the actual target (there may be many controls which support undo).
>> Additionally, before this can happen, the system has to determine wether an 
>> entry is enabled at all — you can't do this when you have only a simple 
>> closure.
>> 
>> Best regards,
>> Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[James Campbell via swift-evolution]

Good point. Not sure if that's replaceable via a protocol or if that Api is 
just not suited for swift. 

There is a proposal somewhere to be able to reference swift methods via back 
ticks a sort of selector for swift so maybe in this case we would use that.

Sent from my iPhone

> On 30 Dec 2015, at 20:27, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> I'm not as familiar with OS X but why is it vital there ?
> 
>> Do you have an example of use ?
> 
> If those questions are for me ;-):
> Afair (have to do iOS most of the time now), "Undo" is the most prominent 
> example. You don't link those menu entries to a concrete object, but rather 
> say "bind this to a selector whose name is…", and then the system can 
> determine the actual target (there may be many controls which support undo).
> Additionally, before this can happen, the system has to determine wether an 
> entry is enabled at all — you can't do this when you have only a simple 
> closure.
> 
> Best regards,
> Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[James Campbell via swift-evolution]

What if selectors arguments could be imported into swift to take a closure 
instead ? 

This would fit into the proposal to rewrite the imported objective c Apis 

So 

- addAction:(Selector)action

Becomes

addAction(action:(AnyObject)->Void)

Instead of

addAction(action:String) 

Like it does now.

Sent from my iPhone

> On 29 Dec 2015, at 21:46, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Dec 29, 2015, at 12:19 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch  
>>> wrote:
>>> 
>>> This is a neat idea. Here are some of my thoughts after initial readthrough:
>>> 
>>> - For symmetry with Obj-C code, how about using "@selector", such as 
>>> @selector(UIView.`insertSubview(_:at:)`) ?
>> 
>> @ means at-tribute in Swift, whereas this is a specific expression. 
>> 
>>> - Or, why bother with a new expression? Could the compiler just do this 
>>> automatically when it encounters an @objc function being passed as a 
>>> Selector? So, you'd simply be able to say "let sel1: Selector = 
>>> UIView.`frame.get`"
>> 
>> It could, but I don't think it should: the operation is not common enough 
>> that making it implicit would reduce overall syntactic noise, and it would 
>> introduce ambiguities between selector- and closure-based APIs. 
> 
> Maybe we can make constructor-like "Selector(Class.method)" syntax work (and 
> "Selector(getterFor:/setterFor: Class.property)" for property accessors) 
> instead of introducing a new magic function name.
> 
> -Joe
> 
>>> - Should the migrator offer to convert string-constant selectors to this 
>>> form?
>> 
>> Yes, absolutely.
>> 
>>> - It might be worth considering this in the context of the "type-safe 
>>> selectors" idea that was floating around a while back.
>> 
>> Yes, I should have referenced that. Apologies!
>> 
>>> - Would it be valid to qualify a function with a subclass's name, when it's 
>>> really only defined on the superclass? That is, would 
>>> "objc_selector(MyView.`frame.get`)" work even if MyView doesn't override 
>>> the `frame` property?
>> 
>> Yes. MyView still has that property even if it doesn't override it. 
>>> 
>>> I could see this last one as a potential source of user confusion, because 
>>> naming a particular class wouldn't actually tell you which implementation 
>>> gets called when performing the selector (that's just the nature of the 
>>> Obj-C runtime).
>> 
>> To some extent, that's the nature of overriding. But objective-c allows one 
>> to use a selector with an unrelated class, which can certainly be confusing. 
>> I feel like that comes from the runtime itself, and isn't something we can 
>> avoid with any syntax we pick. 
>> 
>>> Jacob Bandes-Storch
>>> 
 On Sat, Dec 26, 2015 at 11:48 PM, Douglas Gregor via swift-evolution 
  wrote:
 Hi all,
 
 Currently, producing an Objective-C selector in Swift is an error-prone 
 operation. One effectively just writes a string literal and uses it in a 
 context where an ObjectiveC.Selector is expected:
 
 control.sendAction(“doSomething:”, to: target, forEvent: event)
 
 There are many points of failure here:
 
 1) The compiler doesn’t syntax-check at all to make sure it’s a valid 
 spelling for a selector
 2) The compiler doesn’t look for existing methods with this selector 
 anywhere
 3) The mapping from a Swift method name to an Objective-C selector isn’t 
 always immediately obvious (especially for initializers), and will be 
 getting significantly more complicated with the renaming work for Swift 3 
 (https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md).
 
 I suggest that we add an expression ‘objc_selector(method-reference)` that 
 produces the Objective-C selector for the named method, and produces an 
 error if the method does not have an Objective-C entry point. For example:
 
 control.sendAction(objc_selector(MyApplication.doSomething), to: 
 target, forEvent: event)
 
 “doSomething” is a method of MyApplication, which might even have a 
 completely-unrelated name in Objective-C:
 
 extension MyApplication {
 @objc(jumpUpAndDown:)
 func doSomething(sender: AnyObject?) { … }
 }
 
 By naming the Swift method and having objc_selector do the work to form 
 the Objective-C selector, we free the programming from having to do the 
 naming translation manually and get static checking that the method exists 
 and is exposed to Objective-C.
 
 This proposal composes with my “Generalized Naming for Any Function” 
 proposal, which lets us name methods fully, including getters/setters:
 
 let sel1: Selector 

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[James Campbell via swift-evolution]

Ah good point, in swift you can return a function as a closure (see that link) 
so interface builder could bind an action. Like so :

addAction(myClass.actionFunction)

Instead of what it does now:

addAction(myClass, action:"actionFunction:")


Sent from my iPhone

> On 30 Dec 2015, at 14:14, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
> 
> 
>> Le 30 déc. 2015 à 12:21, James Campbell via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> These are very good points. 
>>> 
>>> Actually, it comes in as addAction(action: Selector), not String. You can 
>>> initialize a Selector from a string literal.
>> 
>> Yes :) should have looked it up before I tried to remember it off the top of 
>> my head.
>> 
>>> 
>>> Three questions about your proposal:
>>> 
>>> 1. Where does "AnyObject -> Void" come from? The only signature information 
>>> in a selector is the (minimum) number of arguments. Those arguments can be 
>>> of any type, and
>> 
>> Well I would want to know what selectors people would us:
>> 
>> One with one argument tend to be for events like button actions and 
>> notifications which could be replaced by closures. We could deprecate or 
>> provide warnings when trying to use the Selector Apis in swift.
>> 
>> Others with more tend to be for canPerformSelector which is replaced by 
>> optionals.
>> 
>> The one edge case not handled is nsinvocation or performSelector, I would be 
>> interested why people use this use case and how we would replace it in swift 
>> (if at all).
>> 
>>> 
>>> 2. How are we supposed to implement this? You need to somehow convert a 
>>> closure (a pointer to a bunch of captured variables with a pointer to a 
>>> function embedded inside it) into a selector (a pointer to a table of 
>>> selectors inside the Objective-C runtime, which does not do any normal 
>>> memory management); I just don't see how you make that work. Saying "let's 
>>> do this thing" doesn't mean it's *possible* to do the thing.
>> 
>> I get that they are different but I had the idea that the compiler could 
>> generate a unique name for each closure which when referenced by a selector 
>> it would invoke.
>> 
>> But this would be irrelevant if we moved towards closure Apis.
>> 
>>> 3. What about other uses for selectors? addAction() is all well and good, 
>>> but you also need removeAction(), and Swift closures don't have stable 
>>> identities to test with.
>> 
>> I question when we use things such as removeAction? I've only used 
>> addAction. But I guess again if we moved to closure Apis this point would be 
>> moot.
>> 
>> To me the only case that needs selectors is performSelector or Nsinvocation. 
>> The others can be replaced by closures and the selector api to be deprecated 
>> or to show a warning in swift :) (Xcode could even help migrate by moving it 
>> to a closure that calls the function the selector was pointing to)
>> 
>> I'm not a compiler expert so I rely on the swift team to tell me what's 
>> possible (although at this early stage I think it's more important to figure 
>> out what we want and not be bound by what's possible right now)
> 
> How would the closure based API work with Interface Builder ? 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] rename dropFirst() and dropLast()

[James Campbell via swift-evolution]

What about shift and pop?

They both could take an argument of a number of items to shift or pop ? 



Sent from my iPhone

On 29 Dec 2015, at 20:25, Brent Royal-Gordon via swift-evolution 
 wrote:

>> I guess that's a good argument for keeping "prefix" and "suffix" instead of 
>> "take" and "takeEnd". But there is no good noun phrase to use for 
>> dropFirst/dropLast (Haskell's "init" and "tail" are nouns but they're very 
>> confusing and don't really make sense once you add in an integral argument 
>> anyway). The guidelines do say it's acceptable to use an imperative verb if 
>> there is no good noun phrase, so "skip" and "skipEnd" (or "skipLast", or 
>> maybe "skipSuffix" if we're keeping "suffix") are still reasonable.
> 
> I'm thinking:
> 
>collection.onlyFirst(5)
>collection.exceptFirst(5)
>collection.onlyLast(5)
>collection.exceptLast(5)
> 
> Perfectly parallel, don't sound like mutating operations, and very clear 
> about which part you keep and which part you toss.
> 
> -- 
> 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] ternary operator ?: suggestion

[James Campbell via swift-evolution]

What if you could wrap the existing switch statement in a closure and return a 
value from that closure like so

Let value = { switch (other) {
Case .Some(let value):
Return value // because this is in a closure the closure will return the value 
not the function this is in
Case .None:
Return "hello" 
}}


Sent from my iPhone

> On 29 Dec 2015, at 07:53, Howard Lovatt via swift-evolution 
>  wrote:
> 
> You can replace the proposed statement `which` (another thread), the existing 
> statement `?:` (this thread), and the global function `??` (which is an odd 
> ball) with matching library methods.
> 
> A library method is likely slower than a built in at this stage until the 
> optimiser improves, but a library function:
> 
> Is documented right in the IDE including code completion, statements aren’t 
> (you don’t see quick help for `for`!)
> Having a library function allows the use case to be throughly investigated. 
> Is worth while as a language statement? What exact features are useful? EG 
> should `which` support pattern matching, general boolean expressions, or 
> simply be `Equatable` as shown below?
> It is simpler to implement, maintain, and change a library function that a 
> built-in.
> There is no need for a keyword.
> 
> First `which`:
> 
> // Alternative to introducing `which` statement
> 
> final
> class Which {
> private
> var result: R?
> 
> private
> let which: I
> 
> init(_ which: I) {
> self.which = which
> }
> 
> func match(value: I, @noescape matchResult: () throws -> R) rethrows -> 
> Self {
> if self.result == nil && self.which == value {
> self.result = try matchResult()
> }
> return self
> }
> 
> func matchDefault(@noescape defaultResult: () throws -> R) rethrows -> R {
> switch self.result {
> case .None:
> return try defaultResult()
> case .Some(let value):
> return value
> }
> }
> }
> 
> 
> // Demo
> enum Color {
> case Red, Blue, Green
> }
> 
> // Which with a default value
> let i1 = Which(Color.Red) // i = 16711680
> .match(.Red)   { 0xFF }
> .match(.Green) { 0x00FF00 }
> .match(.Blue)  { 0x0FF }
> .matchDefault  { 0 }
> 
> // Which that throws an error if it defaults
> let i2: Int! = Which(Color.Green) // i = 16711680
> .match(.Red)   { 0xFF }
> .match(.Green) { 0x00FF00 }
> .match(.Blue)  { 0x0FF }
> .matchDefault  { nil }  // Cant type call to fatalError as no return, 
> hence nil and type Int! (note !)
> 
> Note runtime check for default rather than static check via compiler, not as 
> good but not a big deal most of the time. The vast majority of languages 
> don't do a compiler check on `switch`.
> 
> Similarly the `?:` statement can be replaced:
> 
> // Replacement for `?:` operator
> 
> struct IfFalse {
> private
> let result: R?
> 
> func ifFalse(@noescape falseResult: () throws -> R) rethrows -> R {
> switch self.result {
> case .None:
> return try falseResult()
> case .Some(let value):
> return value
> }
> }
> }
> 
> extension Bool {
> func ifTrue(@noescape trueResult: () throws -> R) rethrows -> 
> IfFalse {
> switch self {
> case true:
> return IfFalse(result: try trueResult())
> case false:
> return IfFalse(result: nil)
> }
> }
> }
> 
> 
> // Demo
> let sB = true.ifTrue{"True"}.ifFalse{"False"} // "True" - for some reason 
> needs {} and not () thinks () form throws
> 
> Whilst the `??` operator is already a library function it is difficult to see 
> in an expression, it gets buried, and is inconsistent in style because it is 
> a non-mathematical operator and a symbol rather than a keyword or keyword 
> followed by a symbol. The space either side of the `??` operator also makes 
> it look like both arguments are of equal importance, whereas it is the left 
> hand side that is important and the right hand side is just a catch.
> 
> // Replacement for `??` operator
> 
> extension Optional {
> func ifNil(@noescape nilResult: () throws -> Wrapped) rethrows -> Wrapped 
> {
> switch self {
> case .None:
> return try nilResult()
> case .Some(let value):
> return value
> }
> }
> }
> 
> 
> // Demo
> let o: String? = nil
> let sO = o.ifNil{"Nil"} // "Nil" - for some reason needs {} and not () thinks 
> () form throws
> 
> 
> Sent from my iPad
> 
>> On 29 Dec 2015, at 4:00 AM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> No exhaustiveness checking is a serious deficiency :-(
>> 
>> -Thorsten
>> 
>>> Am 17.12.2015 um 08:09 schrieb Brent Royal-Gordon via swift-evolution 
>>> :
>>> 
>>> Actually, this *almost* does what you want. No @autoclosure for the values 
>>> and no 

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

What about templatetype ? This could also work if we started referring
generics as Templates :) and extended them to protocols and functions.


On Sat, Dec 26, 2015 at 3:15 PM, Ross O'Brien <narrativium+sw...@gmail.com>
wrote:

> There's a problem here because associated types aren't the same as
> generics.
>
> I've been looking this up a lot recently because I've been trying to
> create a delegate protocol for a generic type. The GenericType requires
> a GenericTypeDelegate and Swift 2 protocols just don't support those
> yet; the best workaround of the moment seems to be a wrapper type which
> wraps the delegate's functions in closures.
>
> This is a different concept to associated types. I've seen a couple of
> examples around; the one I'm remembering at the moment involves a protocol
> for Animals requiring them to have an associated Food type. A Cow could
> thus be defined as a type implementing the Animal protocol, with an
> associated type of Grass; this would be very different to an Animal being a
> generic type, and a Cow being (perhaps typealiased as) an Animal.
> With the associated type, the Cow is known to always eat Grass; with the
> generic type, every function is written to handle all foodstuffs.
>
> So, no, the two different syntaxes are required - but protocols with
> generic parameters (is that the right term for e.g. Grass in
> Animal?) would be a good addition to the language.
>
>
> On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> If we made class, structs, protocols and functions use the same generics
>> syntax then I think it would make it more consistent rather than arguing
>> about which keyword to use. I am for-ever being tripped up by lack of
>> generics in the language.
>>
>> class Array
>> {
>> func first() -> T?
>> }
>>
>> struct Node
>> {
>> var value: Value
>> }
>>
>> Array()
>> Node()
>>
>> or
>>
>> func makeACell() -> T
>> {
>> }
>>
>> makeACell()
>>
>> or
>>
>> protocol Collection
>> {
>> func first() -> Item?
>> }
>>
>> class IntBag : Collection //We bind protocol "associated type" using
>> generic syntax when subclassing. In this case we are saying Item should be
>> type Int
>> {
>> }
>>
>> class Array: Collection //We bind protocol "associated type"
>> using generic syntax when subclassing. In this case we are saying Item
>> should be the same type as the generic type for Array
>> {
>> }
>>
>> IntBag()
>> Array()
>>
>>
>> On Wed, Dec 23, 2015 at 10:58 PM, James Campbell <ja...@supmenow.com>
>> wrote:
>>
>>> They are placeholders because in the protocol:
>>>
>>> prtocotol Collection
>>> {
>>>   placeholder Item
>>>
>>>   func first() -> Item?
>>>  {
>>>  }
>>> }
>>>
>>> Item is a placeholder for a concrete type, at this moment this is a
>>> concept "A collection should return an item of a type" but we don't know
>>> what that type is as its a plaeholder for a type.
>>>
>>> therefore in:
>>>
>>> class IntCollection: Collection
>>> {
>>>placeholder Item = Int
>>> }
>>>
>>> We are saying that the placeholder should now become a concrete type. In
>>> my eyes associated types are nothing more than generics for protocols which
>>> in turn could be argued is some kind of placeholder.
>>>
>>> Associated type means nothing to me, associated to what ? A type could
>>> be associated to many things like a variable, or a generic or whatever. A
>>> placeholder to mean does what it says on the tin. If we moved to protocols
>>> using a syntax closer to generics for classes then I think it would be
>>> simpilar to grasp for beginners .
>>>
>>> On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_r...@apple.com>
>>> wrote:
>>>
>>>> James or Erica (or someone else), can you explain what makes these
>>>> types "placeholders"? I don't think of the other requirements in a protocol
>>>> as "placeholder properties" or "placeholder methods".
>>>>
>>>> My explanation of these things is "When a particular type X conforms to
>>>> a protocol, you can ask about the types that X uses to implement the
>>>> requirements of the pro

Re: [swift-evolution] Lambda function syntax

[James Campbell via swift-evolution]

I don't think either are that nice, we could do a ruby thing and use "do".
The do expresses that we are passing in a block :)  and the arguments are
on the outside of the closure which matches iit elsewhere:

heyThere() do |hi, there|
{

}

we could allow anon functions like so:

heyThere((hi, there){
})

But then its inconsistent, so I don't mind what swift does now :) as its
consistent whether its a closure block or a argument we are passing in.

Regarding the "=>" vs "in" debate, they are both obtuse to me. In some-ways
"in" is better as it reads to me as "the arguments in this closure" so I
would much prefer "in". I know this is subjective but that's just my two
cents ;)

On Wed, Dec 23, 2015 at 9:42 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> love trailing closures
>
> I wouldn't go that far and just say "})" looks ugly — but that has the
> same implications ;-)
> With parameters, trailing closures loose a lot of their appeal, and an
> alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that
> bad for trailing closure either.
>
> The only obvious downside is the "$0" shortcut would be confusing with
> "func() {" (but not so much with "func {"…).
> Speaking of "$0", you could argue why it is allowed in closures and not in
> methods… but I'm in some discord with $0 anyways:
> It is really nice for small constructs, but drawing the line when to
> discourage their use is tough (at least to tough for the compiler to
> enforce a rule).
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

+1 for associated

On Wed, Dec 23, 2015 at 10:08 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> >> I did see that point made earlier in the thread, but I’m not convinced
> that design for googleability is the right ordering of priorities.
> > +1
> > Choosing cryptic names because it's easier to find information about
> them is bad. With this argument, you can not only fight against removal of
> the NextStep prefix (Data, Number, Date… try googling that), but also
> demand that the language should be spelled "Sweeft", and that framework
> functions should loose their meaningful names and get called by a UUID
> instead.
>
> I don't think the `associated` keyword is cryptic; I think it's
> *specific*. "Associated type" is the name of this feature. We tried
> bikeshedding it upthread, and didn't come up with anything better. If
> you're going to use a keyword related to the name "associated type", that
> leaves you with `associated`, `type`, or `associatedtype`. Of these three,
> `type` is extremely vague (and also something we've resisted taking as a
> keyword—see the discussion about `SomeType.self` last week),
> `associatedtype` is an overlong, awkward concatenation of two words, and
> `associated` has neither of those failings. That's why I favor it.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

In fact why not just use the generics syntax with protocols ?  Anybody
implementing a "Generic" Protocol has to specify the types.

protocol Collection
{

func get(key: Key) -> Value?
}

class StringCollection: Collection
{

}

class GenericCollection: Collection
{

}

On Wed, Dec 23, 2015 at 11:18 AM, James Campbell  wrote:

> Maybe you could use the phrase "placeholder" type. If you think about it.
> typealias is a way of "aliasing" the type. i.e "Type B is just another name
> for Type C"
>
> Associated type I always found a bit confusing, associated with what ? A
> placeholder type I feel explains it more plainly. Associated types are
> nothing but placeholders.
>
> So this is my example:
>
> protocol Collection
> {
> typeplaceholder T
>
> func first() -> T?
> }
>
> class IntCollection: Collection
> {
>typeplaceholder T = Int
> }
>
> potentially you could provide some sort of syntax for setting it in the
> subclass part of the code.
>
>
> protocol Collection
> {
> typeplaceholder T
>
> func first() -> T?
> }
>
> class IntCollection: Collection //The T type placeholder is now an
> Int
> {
>
> }
>
> class GenericCollection: Collection //The T type placeholder is
> now what ever the generic F is set to.
> {
>
> }
>
> On Wed, Dec 23, 2015 at 11:00 AM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > "Associated type" is the name of this feature
>> The name of the concept is highly inexpressive, and I guess it's far
>> easier to change the docs than to change the language…
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

If part of this proposal is to update documentation to refer to it as
"placeholder" typed then I am okay with "type"

On Wed, Dec 23, 2015 at 1:15 PM, Craig Cruden  wrote:

> I prefer “type”.
>
>
> On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I would agree to stop talking about associated types and start talking
> about placeholder types instead.
> But as a keyword, IMO the problem is that `placeholder` is not appropriate
> to define the implementation.
>
> eg
> class Foo: Stream {
> placeholder Payload = String // IMO doesn't feel right
> type Payload = String // IMO feels good
> }
>
> --
> Pierre
>
> Le 23 déc. 2015 à 13:59, James Campbell  a écrit :
>
> I think we should use "placeholder" it more accurately describes what it
> does. For a bigger change then I would propose my protocol generics idea.
>
> On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks
>> good to me.
>>
>> eg:
>>
>> protocol Stream {
>> type Payload
>> var ready: Bool { get }
>> func read() -> Payload?
>> }
>>
>> protocol Collection {
>> type Element
>> var count: Int { get }
>> func contains(element: Element) -> Bool
>> }
>>
>>
>> --
>> Pierre
>>
>> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> Hi,
>>
>> I’m starting a new thread for this proposal
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>
>> So far, everybody agreed that using distinct keywords for type alias and
>> associated type declarations is a good idea.
>> However, some people think that “associated” is not an ideal replacement
>> because it is too vague.
>> I would like to choose a better keyword before the review, but I’m
>> struggling to find a good replacement.
>>
>> So, here are some keywords that were proposed by the community.
>>
>> 1. associated_type
>> This is the original proposed keyword. It is extremely clear, but
>> snake_cases are un-Swifty.
>>
>> 2. associatedtype (or typeassociation)
>> This was the first alternative to associated_type. Its purpose is still
>> extremely clear.
>> I like it a lot, but it is a bit long and difficult to read.
>>
>> 3. associated
>> This is the keyword I chose for the proposal because it was the most
>> well-received initially.
>> It is quite short, very different from “typealias", and sounds good.
>> However, it is also vaguer.
>> Because the word “type” is not in it, it’s unclear what should follow it,
>> and it’s unclear what it declares.
>> For example, one could think that it is an associated *value* and write
>> protocol FixedSizeCollectionProtocol {
>> associated size : Int
>> }
>> Although honestly I doubt many people would write that.
>>
>> 4. withtype (or needstype)
>> It is short, somewhat easy to read, has the word “type” in it, and some
>> concept of association thanks to “with”. I like it.
>> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>>
>> 5. type
>> This keyword was proposed by several people, but I strongly dislike it.
>> It conflicts with an other proposal about unifying the “static” and
>> “class” keywords for type-level members.
>> I think the fact that it was proposed for two completely different
>> purposes shows that it is too abstract.
>> It would make searching for help more difficult because of its bad
>> googleability.
>>
>>
>> Personally, I would like to either keep “associated”, or use
>> “associatedtype” because they are the most obvious choices.
>>
>> 1) Do you agree about using “associatedtype”?
>> 2) If not, which keyword would you prefer to use? why? (you can introduce
>> a new one)
>> Bonus) Maybe some twitter-famous person could make a quick poll and see
>> which one developers prefer?  (after they read this email)
>> I would gladly do it myself, but I don’t think my twenty (mostly fake)
>> followers will give me a lot of information.
>>
>> Loïc
>>
>> ___
>> 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
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Mixins

[James Campbell via swift-evolution]

Mixins would be a great addition instead of having to define a protocol and 
then extending it 

Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

They are placeholders because in the protocol:

prtocotol Collection
{
  placeholder Item

  func first() -> Item?
 {
 }
}

Item is a placeholder for a concrete type, at this moment this is a concept
"A collection should return an item of a type" but we don't know what that
type is as its a plaeholder for a type.

therefore in:

class IntCollection: Collection
{
   placeholder Item = Int
}

We are saying that the placeholder should now become a concrete type. In my
eyes associated types are nothing more than generics for protocols which in
turn could be argued is some kind of placeholder.

Associated type means nothing to me, associated to what ? A type could be
associated to many things like a variable, or a generic or whatever. A
placeholder to mean does what it says on the tin. If we moved to protocols
using a syntax closer to generics for classes then I think it would be
simpilar to grasp for beginners .

On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_r...@apple.com> wrote:

> James or Erica (or someone else), can you explain what makes these types
> "placeholders"? I don't think of the other requirements in a protocol as
> "placeholder properties" or "placeholder methods".
>
> My explanation of these things is "When a particular type X conforms to a
> protocol, you can ask about the types that X uses to implement the
> requirements of the protocol". I guess we could call them "related types"
> instead of "associated types", but that doesn't seem significantly
> different.
>
> Jordan
>
>
> > On Dec 23, 2015, at 12:42, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The thing is associated type means nothing to me, it's too technical.
> Placeholder type I think would be better even if it's only what we called
> it in the documentation
> >
> > Sent from my iPhone
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mixins

[James Campbell via swift-evolution]

We should get this as a proposal in. That case so it doesn't slip off the radar 
if that is the case

Sent from my iPhone

> On 23 Dec 2015, at 19:57, Stephen Celis <stephen.ce...@gmail.com> wrote:
> 
> I remember reading another thread (the associated/typealias renaming 
> discussion) where an Apple engineer wrote that this limitation is temporary 
> and that functions should be definable directly in a protocol. If that's the 
> case, this may just be a bug and not have to go through evolution.
> 
> Stephen
> 
>> On Dec 23, 2015, at 2:54 PM, James Campbell via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Mixins would be a great addition instead of having to define a protocol and 
>> then extending it 
>> 
>> Sent from my iPhone
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

>
>
> > In fact why not just use the generics syntax with protocols ?  Anybody
> implementing a "Generic" Protocol has to specify the types.
> That's a simple solution, but inconvenient:
> One use case for placeholders (I don't use the official name here to
> propagate an alternative ;-) is when you have a types that depend on a
> parameter.
> I'm to lazy to look up a real example, but Array is naturally
> associated with an enumerator for Int — and it is no fun to be forced to
> include such relationships all over the place.


So in my example with placeholders.

class GenericCollection: Collection
{

}

Has already specified the type of the placeholder :) so subclasses don't
need to specify it. In this example the Key and Value type placeholders are
bound to whatever the Type is.

So in these examples

let items: GenericCollection = GenericCollection()

or

let items: [Int] = []

the Key and Value type placeholders would be Ints :) since the generic type
is an Int.


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

I think we should use "placeholder" it more accurately describes what it
does. For a bigger change then I would propose my protocol generics idea.

On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks
> good to me.
>
> eg:
>
> protocol Stream {
> type Payload
> var ready: Bool { get }
> func read() -> Payload?
> }
>
> protocol Collection {
> type Element
> var count: Int { get }
> func contains(element: Element) -> Bool
> }
>
>
> --
> Pierre
>
> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hi,
>
> I’m starting a new thread for this proposal
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>
> So far, everybody agreed that using distinct keywords for type alias and
> associated type declarations is a good idea.
> However, some people think that “associated” is not an ideal replacement
> because it is too vague.
> I would like to choose a better keyword before the review, but I’m
> struggling to find a good replacement.
>
> So, here are some keywords that were proposed by the community.
>
> 1. associated_type
> This is the original proposed keyword. It is extremely clear, but
> snake_cases are un-Swifty.
>
> 2. associatedtype (or typeassociation)
> This was the first alternative to associated_type. Its purpose is still
> extremely clear.
> I like it a lot, but it is a bit long and difficult to read.
>
> 3. associated
> This is the keyword I chose for the proposal because it was the most
> well-received initially.
> It is quite short, very different from “typealias", and sounds good.
> However, it is also vaguer.
> Because the word “type” is not in it, it’s unclear what should follow it,
> and it’s unclear what it declares.
> For example, one could think that it is an associated *value* and write
> protocol FixedSizeCollectionProtocol {
> associated size : Int
> }
> Although honestly I doubt many people would write that.
>
> 4. withtype (or needstype)
> It is short, somewhat easy to read, has the word “type” in it, and some
> concept of association thanks to “with”. I like it.
> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>
> 5. type
> This keyword was proposed by several people, but I strongly dislike it.
> It conflicts with an other proposal about unifying the “static” and
> “class” keywords for type-level members.
> I think the fact that it was proposed for two completely different
> purposes shows that it is too abstract.
> It would make searching for help more difficult because of its bad
> googleability.
>
>
> Personally, I would like to either keep “associated”, or use
> “associatedtype” because they are the most obvious choices.
>
> 1) Do you agree about using “associatedtype”?
> 2) If not, which keyword would you prefer to use? why? (you can introduce
> a new one)
> Bonus) Maybe some twitter-famous person could make a quick poll and see
> which one developers prefer?  (after they read this email)
> I would gladly do it myself, but I don’t think my twenty (mostly fake)
> followers will give me a lot of information.
>
> Loïc
>
> ___
> 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
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[James Campbell via swift-evolution]

Why not just do ?

On Wed, Dec 23, 2015 at 1:02 PM, Daniel Valls Estella via swift-evolution <
swift-evolution@swift.org> wrote:

> I think => may be confusing in many of shown cases. Its a cause/efect
> symbol and can be also and operator.
>
> I put again the idea of with for the newcomers:
>
> with (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *with*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *with*{ $0 > $1 } )
>
>
> sorted = names.sort()  *with* { $0 > $1 }
>
> reversed = names.sort *with*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *with* { $0 > $1 }
>
>
> But thinking about it, what we are really always doing with clousures is
> solving a quicky tiny delegation pattern. Maybe we could name it what it
> is. Too long word, but just to brainstorm.
>
> delegating (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *delegating*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *delegating*{ $0 > $1 } )
>
>
> sorted = names.sort()  *delegating*{ $0 > $1 }
>
> reversed = names.sort *delegating*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *delegating*{ $0 > $1 }
>
>
>
> :)
>
> El 23 des 2015, a les 12:49, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> va escriure:
>
> I like that the closure parameters are inside the closure, to me it makes
> as much sense as outside. They're the input, so as much in as out.
>
> I have nothing against `in`, but I wouldn't be against a sensible
> replacement.
> I like `=>`, but I'm concerned it might be confused with `->` by beginners
> in swift.
>
> --
> Pierre
>
> Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I have to admit I haven't read the entire thread, so maybe I missed
> discussion of this.
>
> I, too, don't like the `params in code` syntax. After a year and a half
> with Swift, I now remember it, but it still reads funny, and I see new
> developers struggle with it frequently. I've also used Ruby quite a bit,
> but I really don't like the `||` syntax there either.
>
> What I would do is pull the parameters/type signature out of the braces
> and put a symbol in front of them. For example:
>
> let names = people.map => person { person.name }
>
> database.saveRecord(record) => record, error {
> if let record = record {
> completionHandler(true)
> }
> else {
> handleError(error!)
> }
> }
>
> `=>` is used here merely because it's been discussed upthread; I actually
> think it's a little too heavy for this role, but I don't have a great
> replacement immediately at hand.
>
> A no-parameters closure would not require a `=>`; a bare block would still
> do there. I suppose the capture list would still go before the parameters,
> but after the `=>`. Other closure features remain the same—you can still
> use the `$N` implicit parameters, and you can still use `->` to specify a
> return value, `()` to surround the parameters, `:` to specify exact types,
> etc.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[James Campbell via swift-evolution]

I like the point someone made about unit testing. If subclassing was
disabled then I think there should then be some way of mocking built into
the testing frameworks of swift (Think RSpec but for switt)

On Tue, Dec 22, 2015 at 12:51 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote:
>
>
> I can see why you view it this way, but access control and inheritability
> are orthogonal.
>
> as I understand orthogonal (mathematical background), it is definitely not
> the case:
> I can't inherit what I cannot access, so there is one impossible
> combination of the two attributes.
>
>
> Ok, you got me there.  Orthogonal was not the best choice of words.
> Nevertheless, they are independent concerns that happen to interact in this
> one case.
>
>
> The argumentation that "users of your framework could cause trouble (what
> they will do anyways ;-) with overriding" looses traction when you have to
> add "of cause that only applies to classes you made explicitly accessible
> to them".
>
> Final is right in theory, but in real software, classes are rarely
> designed for inheritance — it just happens (and I'm quite sure most real
> software is build by people who would shrug of such discussions as academic
> nonsense ;-).
>
>
> If the time comes it is certainly a good thing if the language can remind
> you of the fact that you didn't consider it in the initial implementation
> by requiring you to mark the superclass inheritable.
>
>
> Btw: I wouldn't oppose a proposal to allow changing conventions like this
> (there are at least two other discussions about the best default) on a per
> module/file basis — as long as the "local" effect of the setting isn't
> vital, there shouldn't be a problem with customizing.
>
>
> I would really be opposed to this.  It would not be clear when reading
> code what it actually means.  Copy and paste would also be problematic for
> similar reasons.  Flags should not change the semantics of a piece of code.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[James Campbell via swift-evolution]

Also in future versions features may go away meaning older libraries may assume 
that greater than swift 2 is all that is needed to imply compatibility. Also 
libraries may be written against features they may not know which version of 
swift it will get into. Additionally certain features aren't available across 
platforms so how do you know what swift 2 means across platforms ? 

Swift version conditionals are a useful fallback but we should also try and 
make feature conditionals a first class citizen too. 

I love the @supports syntax in CSS, if we could do that then that would be 
awesome :)  it's a great way of handling implementations across platforms 

Sent from my iPhone

On 20 Dec 2015, at 21:00, Andrey Tarantsov via swift-evolution 
 wrote:

>> I suspect with the race to a stable language, the plan is to design features 
>> as if the language were to stay solid.
> 
> Are you implying that Swift 4 will have zero new features? Nothing that 
> libraries will want to use conditionally when available?
> 
> A.
> 
> ___
> 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] Swift 2.2: #if swift language version

[James Campbell via swift-evolution]

I think we should be moving towards feature detection over swift version 
detection



Sent from my iPhone

> On 20 Dec 2015, at 06:32, Dirk Schreib via swift-evolution 
>  wrote:
> 
> 
>> On 20 Dec 2015, at 07:01, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> Sounds like it could be super useful for libraries!
>> 
>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> 
> I agree with Radek.
> 
> The argument to use a string is if we wanted to support subversions, e.g. 
> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
> displeased.
> 
> However, I don’t think we *want* the feature to be able to do that.  The 
> most important use case for this feature is to handle syntactic 
> differences across swift versions, and we don’t want those in 
> sub-versions.  Given that, it seems better to keep the syntax clean and 
> simple.
 
 This feature LGTM, and I also prefer that we drop the quotes. Two levels 
 of version number should be sufficient.
 
   - Doug
>>> 
>>> Chris brought something up that a few of us had discussed in the past: the 
>>> ambiguity of what the operation does. It's implicitly "current version >= 
>>> specified version", but I wonder how many people will want to compare 
>>> otherwise or will assume the comparison is '=='.
>>> 
>>> We can fix this in two ways:
>>> 
>>> Option 1: #if swift(>> 
>>> or
>>> 
>>> Option 2: #if swift > x.y
>>> 
>>> I thought I preferred Option 1 but I think Option 2 reads more how you 
>>> would expect and somewhat reflects the regular syntax of the language, 
>>> FWIW. I sketched out both implementations and they're about the same in 
>>> complexity, so I would suggest Option 2, unless it's a strong goal to keep 
>>> special sauce in build configurations as "function calls".
>>> 
>>> Maybe not all of the comparison operators are necessary, but in general 
>>> this gives some flexibility to arrange checks (newer code at the top or at 
>>> the bottom) and actually describes what comparison is happening.
>> 
>> I don't like either of these. I especially don't like option 2 because it 
>> makes "swift" something magic while user flags are still limited to 
>> booleans, and I don't think we're likely to change user flags any time soon. 
>> But I don't like option 1 either. We didn't do it for "if #available(…)", 
>> and I don't think we need to do it here either.
>> 
>> Jordan
> What about the following syntax?
> #if Swift.sinceVersion( 2, minor: 2 )
> or even better:
> #if Swift.isFeatureAvailable( "foo" )
> The look is standard Swift. Just at compile time. In both cases optional 
> parameter values are possible. 
> 
> - Dirk
> 
> 
> ___
> 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