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 > <[email protected]> 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 > <[email protected]>: > >> 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 >> ([email protected]) schrieb: >> >>> +1 >>> >>> L >>> >>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >>> <[email protected]> wrote: >>> > >>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution >>> >> <[email protected]> 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 >>> >>> <[email protected]> wrote: >>> >>> >>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution >>> >>> <[email protected]> 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 >>> >>> [email protected] >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >>> >> _______________________________________________ >>> >> swift-evolution mailing list >>> >> [email protected] >>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>> > >>> > _______________________________________________ >>> > swift-evolution mailing list >>> > [email protected] >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
