Re: [swift-users] Question about typo fixes on the Swift website.

[Mayur Dhaka via swift-users]

Thank you for the answers. I’ll be happy to file a PR but I can’t find the 
source for swift.org . Specifically, the source for this 
page: https://swift.org/contributing/ 

Thanks for your time.
— Mayur

PS: (Apologies for the blank email)

> On 09-Oct-2017, at 2:49 PM, Mayur Dhaka <8mayurdhaka.sw...@gmail.com> wrote:
> 
> 
> 
>> On 09-Oct-2017, at 1:28 PM, Slava Pestov > > wrote:
>> 
>> Alternatively, a pull request to fix those typos would be most welcome!
>> 
>> Slava
>> 
>>> On Oct 9, 2017, at 12:58 AM, Alex Blewitt via swift-users 
>>> > wrote:
>>> 
>>> Probably the best place would be to file an issue at https://bugs.swift.org 
>>>  and it can be routed from there.
>>> 
>>> Thanks!
>>> 
>>> Alex
>>> 
 On 8 Oct 2017, at 16:31, Mayur Dhaka via swift-users 
 > wrote:
 
 Hello,
 
 I recently came across a couple of typos in the ‘Contributing’ document on 
 Swift.org . I wanted to know what the preferred place 
 to raise these issues might be? 
 
 Thanks for your time.
 — Mayur
 ___
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
> 

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

Re: [swift-users] Question about typo fixes on the Swift website.

[Mayur Dhaka via swift-users]

> On 09-Oct-2017, at 1:28 PM, Slava Pestov  wrote:
> 
> Alternatively, a pull request to fix those typos would be most welcome!
> 
> Slava
> 
>> On Oct 9, 2017, at 12:58 AM, Alex Blewitt via swift-users 
>> > wrote:
>> 
>> Probably the best place would be to file an issue at https://bugs.swift.org 
>>  and it can be routed from there.
>> 
>> Thanks!
>> 
>> Alex
>> 
>>> On 8 Oct 2017, at 16:31, Mayur Dhaka via swift-users >> > wrote:
>>> 
>>> Hello,
>>> 
>>> I recently came across a couple of typos in the ‘Contributing’ document on 
>>> Swift.org . I wanted to know what the preferred place to 
>>> raise these issues might be? 
>>> 
>>> Thanks for your time.
>>> — Mayur
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

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

Re: [swift-users] [Feature Request] Extend the `defer` statement

[Jun Zhang via swift-users]

Hi Jay,
   I'm wrong and please ignore the "Input parameter" because I can already
get them within the defer statement body.
   Since we have a `newValue` keyword in `didSet` statement, I think a
`returnValue` keyword will be fine.

On Mon, Oct 9, 2017 at 4:49 PM, Geordie Jay  wrote:

> This feature request is probably one for swift evolution.
>
> I like the idea in theory, but I’d prefer to see the return value
> identifier being spelled out, i.e. “returnValue” instead of the symbols.
>
> Jun Zhang via swift-users  schrieb am Mo. 9. Okt.
> 2017 um 05:37:
>
>> Yes that's true, but this requires me to set a return value in every
>> `early return` statement. I think this should be done by the compiler
>> instead of me, to make code cleaner and also less error-prone.
>>
>> On Mon, Oct 9, 2017 at 11:24 AM, Slava Pestov  wrote:
>>
>>> I think you can achieve what you want by having the ‘defer’ block
>>> capture a mutable local variable. Eg,
>>>
>>> func doStuff() {
>>>   var success = false
>>>
>>>   defer {
>>> if !success {
>>>   // do some additional cleanup
>>> }
>>>   }
>>>
>>>   …
>>>   success = true
>>>   …
>>>
>>>   return result
>>> }
>>>
>>> On Oct 8, 2017, at 7:34 PM, Jun Zhang via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> Hi dear swift developers,
>>>I am kind of new to swift and I don't know if this feature already
>>> exists. And if it exists already please tell me how. Thank you very much!
>>>   The feature is to capturing the return value (maybe input value also)
>>> of the function. Here is the demo code:
>>>
>>> func tableView(_ tableView: UITableView, numberOfRowsInSection
>>> section: Int) -> Int {
>>> defer {
>>> if $> >= 0 {
>>> // table is not empty
>>> }
>>> else {
>>> // table is empty
>>> }
>>> }
>>> return dataSource.cout
>>> }
>>>
>>>I suggest using `$>` as the return value symbol and `$<` as the input
>>> parameter symbol.
>>>
>>>
> Also, I’m not sure what “input parameter” means here.
>
> Geordie
>
>
>Thank you all and best regards to you!
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>>
>>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [Feature Request] Extend the `defer` statement

[Geordie Jay via swift-users]

This feature request is probably one for swift evolution.

I like the idea in theory, but I’d prefer to see the return value
identifier being spelled out, i.e. “returnValue” instead of the symbols.

Jun Zhang via swift-users  schrieb am Mo. 9. Okt.
2017 um 05:37:

> Yes that's true, but this requires me to set a return value in every
> `early return` statement. I think this should be done by the compiler
> instead of me, to make code cleaner and also less error-prone.
>
> On Mon, Oct 9, 2017 at 11:24 AM, Slava Pestov  wrote:
>
>> I think you can achieve what you want by having the ‘defer’ block capture
>> a mutable local variable. Eg,
>>
>> func doStuff() {
>>   var success = false
>>
>>   defer {
>> if !success {
>>   // do some additional cleanup
>> }
>>   }
>>
>>   …
>>   success = true
>>   …
>>
>>   return result
>> }
>>
>> On Oct 8, 2017, at 7:34 PM, Jun Zhang via swift-users <
>> swift-users@swift.org> wrote:
>>
>> Hi dear swift developers,
>>I am kind of new to swift and I don't know if this feature already
>> exists. And if it exists already please tell me how. Thank you very much!
>>   The feature is to capturing the return value (maybe input value also)
>> of the function. Here is the demo code:
>>
>> func tableView(_ tableView: UITableView, numberOfRowsInSection
>> section: Int) -> Int {
>> defer {
>> if $> >= 0 {
>> // table is not empty
>> }
>> else {
>> // table is empty
>> }
>> }
>> return dataSource.cout
>> }
>>
>>I suggest using `$>` as the return value symbol and `$<` as the input
>> parameter symbol.
>>
>>
Also, I’m not sure what “input parameter” means here.

Geordie


   Thank you all and best regards to you!
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users