[Pitch] Make `return` optional in computed properties for a single case

The idea is simple:

Can we make return keyword optional in cases like this?
Shouldn’t this behave like @autoclosure or @noescape?
type A {
    var characters: [Character] = …
    var string: String { String(self.characters) }
    var count: Int { 42 }
}
Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

···

--
Adrian Zubarev
Sent with Airmail

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?

This actually doesn't have anything to do with @autoclosure or @noescape. Any one-expression closure can omit the `return` statement and have an inferred return type.

type A {
    var characters: [Character] = …
    var string: String { String(self.characters) }
    var count: Int { 42 }
}

Despite those inaccuracies, I do think that it's a good idea to permit single-expression accessors to omit the `return` statement; it will make them much less clunky. I would even extend this to cases where you use the `get` keyword:

  var string: String {
    get { String(self.characters) }
    set { characters = Array(newValue.characters) }
  }

···

--
Brent Royal-Gordon
Architechies

The idea is simple:

   • Can we make return keyword optional in cases like this?
   • Shouldn’t this behave like @autoclosure or @noescape?

This actually doesn't have anything to do with @autoclosure or @noescape. Any one-expression closure can omit the `return` statement and have an inferred return type.

type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
}

Despite those inaccuracies, I do think that it's a good idea to permit single-expression accessors to omit the `return` statement; it will make them much less clunky. I would even extend this to cases where you use the `get` keyword:

   var string: String {
       get { String(self.characters) }
       set { characters = Array(newValue.characters) }
   }

+1. And in single-expression functions as well. This is something that should be consistent and allowed everywhere in the language.

···

Sent from my iPad
On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

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

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

···

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?
type A {
    var characters: [Character] = …
    var string: String { String(self.characters) }
    var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

+ 1 from me as well for the already stated reasons.

- Dennis

···

On May 28, 2016, at 2:15 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?

This actually doesn't have anything to do with @autoclosure or @noescape. Any one-expression closure can omit the `return` statement and have an inferred return type.

type A {
  var characters: [Character] = …
  var string: String { String(self.characters) }
  var count: Int { 42 }
}

Despite those inaccuracies, I do think that it's a good idea to permit single-expression accessors to omit the `return` statement; it will make them much less clunky. I would even extend this to cases where you use the `get` keyword:

  var string: String {
      get { String(self.characters) }
      set { characters = Array(newValue.characters) }
  }

+1. And in single-expression functions as well. This is something that should be consistent and allowed everywhere in the language.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

+1. Completely agree with Brent's views here.

···

On 28 May 2016, at 9:15 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

   • Can we make return keyword optional in cases like this?
   • Shouldn’t this behave like @autoclosure or @noescape?

This actually doesn't have anything to do with @autoclosure or @noescape. Any one-expression closure can omit the `return` statement and have an inferred return type.

type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
}

Despite those inaccuracies, I do think that it's a good idea to permit single-expression accessors to omit the `return` statement; it will make them much less clunky. I would even extend this to cases where you use the `get` keyword:

   var string: String {
       get { String(self.characters) }
       set { characters = Array(newValue.characters) }
   }

--
Brent Royal-Gordon
Architechies

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

I’m a +1 to this, this is something that keeps catching me out as I’m so used to omitting return in other closures, and that’s essentially all a computer property is anyway so it makes sense for the behaviour to be consistent.

···

On 27 May 2016, at 18:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

Can we make return keyword optional in cases like this?
Shouldn’t this behave like @autoclosure or @noescape?
type A {
    var characters: [Character] = …
    var string: String { String(self.characters) }
    var count: Int { 42 }
}
Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

+1. This has always tripped me up, I guess I felt there was a good reason for requiring you to add a `return`, but not sure what it would be.

···

On 28 May 2016, at 3:57 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

Can we make return keyword optional in cases like this?
Shouldn’t this behave like @autoclosure or @noescape?
type A {
    var characters: [Character] = …
    var string: String { String(self.characters) }
    var count: Int { 42 }
}
Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

···

On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?
type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

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

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

···

On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?
type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

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

I'll write a small proposal tomorrow for that behavior (not only for computed properties of course)! Today I'm too busy.

Thank you for your positive feedback.

···

--
Adrian Zubarev
Sent with Airmail

Am 28. Mai 2016 um 10:11:26, David Hart (david@hartbit.com(mailto:david@hartbit.com)) schrieb:

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>
> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>
> > The idea is simple:
> >
> > • Can we make return keyword optional in cases like this?
> > • Shouldn’t this behave like @autoclosure or @noescape?
> > type A {
> > var characters: [Character] = …
> > var string: String { String(self.characters) }
> > var count: Int { 42 }
> > }
> >
> > Is this worth a proposal or Swifty enough, what do you think?
> >
> > Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>
> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>
> /brian
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.

···

On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

  • Can we make return keyword optional in cases like this?
  • Shouldn’t this behave like @autoclosure or @noescape?
type A {
  var characters: [Character] = …
  var string: String { String(self.characters) }
  var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

_______________________________________________
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

+1

L

···

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.

On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

    • Can we make return keyword optional in cases like this?
    • Shouldn’t this behave like @autoclosure or @noescape?
type A {
  var characters: [Character] = …
  var string: String { String(self.characters) }
  var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

_______________________________________________
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

Here is the draft proposal: https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to provide feedback so I can fix the proposal before I submit a PR.

···

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution (swift-evolution@swift.org) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.

On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

The idea is simple:

• Can we make return keyword optional in cases like this?
• Shouldn’t this behave like @autoclosure or @noescape?
type A {
var characters: [Character] = …
var string: String { String(self.characters) }
var count: Int { 42 }
}

Is this worth a proposal or Swifty enough, what do you think?

Sure I could write return, but why do we allow this behavior for @noescape functions like map!?

While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.

/brian

_______________________________________________
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

Here is the draft proposal: https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md
Did I covered everything case? If you find some mistakes feel free to provide feedback so I can fix the proposal before I submit a PR.

This is a good start.

"Make return optional and infer return type for single-expressions everywhere in the language:”

Everywhere in the language is too strong. We should be more precise. I believe we are talking about top level code blocks that only contain a single expression for the following constructs in the grammar:

function-body
getter-setter-block
getter-clause
variable-declaration
subscript-declaration

Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause.

-Matthew

···

On May 31, 2016, at 12:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>>> The idea is simple:
>>>>
>>>> • Can we make return keyword optional in cases like this?
>>>> • Shouldn’t this behave like @autoclosure or @noescape?
>>>> type A {
>>>> var characters: [Character] = …
>>>> var string: String { String(self.characters) }
>>>> var count: Int { 42 }
>>>> }
>>>>
>>>> Is this worth a proposal or Swifty enough, what do you think?
>>>>
>>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> _______________________________________________
>>> 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 <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Under "Proposed solution" you say (emphasis mine):

"Make return optional and infer return type for single-expressions everywhere in the language:"

However the return type isn't inferred for computed properties or functions, and I don't see type inference being discussed in the proposal (other than mentioning that closures have it).

- David

···

31 maj 2016 kl. 19:35 skrev Adrian Zubarev via swift-evolution <swift-evolution@swift.org>:

Here is the draft proposal: https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to provide feedback so I can fix the proposal before I submit a PR.

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution (swift-evolution@swift.org) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>>> The idea is simple:
>>>>
>>>> • Can we make return keyword optional in cases like this?
>>>> • Shouldn’t this behave like @autoclosure or @noescape?
>>>> type A {
>>>> var characters: [Character] = …
>>>> var string: String { String(self.characters) }
>>>> var count: Int { 42 }
>>>> }
>>>>
>>>> Is this worth a proposal or Swifty enough, what do you think?
>>>>
>>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> _______________________________________________
>>> 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

Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause.
I didn’t get this at first but now I see your point, it’s because the whole returning scope will need `return` at the very end so `guard` should follow that rule.

···

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 21:00:43, Matthew Johnson (matthew@anandabits.com) schrieb:

I really like the proposal in case of properties and functions, but I really don't want to have
guard boolean else { "false" }

I feel like `return` is very important part of `guard` statement.
I understand the requirement for consistency with properties/closures/functions, but I'll prefer to have some inconsistency in language in this case and require `return` for `guard`. And in case I'll have to choose all-or-nothig, I'll give -1 for the proposal.

I.e. IMO current `return` in properties and functions is less evil than absent of `return` in `guard`.

···

On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:

Here is the draft proposal:
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to
provide feedback so I can fix the proposal before I submit a PR.

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
(swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>>> The idea is simple:
>>>>
>>>> • Can we make return keyword optional in cases like this?
>>>> • Shouldn’t this behave like @autoclosure or @noescape?
>>>> type A {
>>>> var characters: [Character] = …
>>>> var string: String { String(self.characters) }
>>>> var count: Int { 42 }
>>>> }
>>>>
>>>> Is this worth a proposal or Swifty enough, what do you think?
>>>>
>>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> _______________________________________________
>>> 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

I'd interpret that as being able to write:
var x: Int8 { 20 }
as opposed to:
var x: Int8 { Int8(20) }

- Dave Sweeris

···

On May 31, 2016, at 12:47, David Rönnqvist via swift-evolution <swift-evolution@swift.org> wrote:

Under "Proposed solution" you say (emphasis mine):

"Make return optional and infer return type for single-expressions everywhere in the language:"

However the return type isn't inferred for computed properties or functions, and I don't see type inference being discussed in the proposal (other than mentioning that closures have it).

- David

31 maj 2016 kl. 19:35 skrev Adrian Zubarev via swift-evolution <swift-evolution@swift.org>:

Here is the draft proposal: https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to provide feedback so I can fix the proposal before I submit a PR.

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution (swift-evolution@swift.org) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>>> The idea is simple:
>>>>
>>>> • Can we make return keyword optional in cases like this?
>>>> • Shouldn’t this behave like @autoclosure or @noescape?
>>>> type A {
>>>> var characters: [Character] = …
>>>> var string: String { String(self.characters) }
>>>> var count: Int { 42 }
>>>> }
>>>>
>>>> Is this worth a proposal or Swifty enough, what do you think?
>>>>
>>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

I really like the proposal in case of properties and functions, but I really don't want to have
guard boolean else { "false” }

+1. This is example *is not* a single expression code block. There are 3 expressions (the condition, the return value in the else block, and the primary return value).

···

On May 31, 2016, at 1:16 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

I feel like `return` is very important part of `guard` statement.
I understand the requirement for consistency with properties/closures/functions, but I'll prefer to have some inconsistency in language in this case and require `return` for `guard`. And in case I'll have to choose all-or-nothig, I'll give -1 for the proposal.

I.e. IMO current `return` in properties and functions is less evil than absent of `return` in `guard`.

On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:

Here is the draft proposal:
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to
provide feedback so I can fix the proposal before I submit a PR.

--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
(swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>>> The idea is simple:
>>>>
>>>> • Can we make return keyword optional in cases like this?
>>>> • Shouldn’t this behave like @autoclosure or @noescape?
>>>> type A {
>>>> var characters: [Character] = …
>>>> var string: String { String(self.characters) }
>>>> var count: Int { 42 }
>>>> }
>>>>
>>>> Is this worth a proposal or Swifty enough, what do you think?
>>>>
>>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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