Is it widely agreed that it is necessary to require a return statement on a one
line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me
it seems redundant; the word `get` literally prece
+1
We don’t need “return” in single-line closures where the type is known, and
I don’t see why it is required in single-line getters.
Nevin
On Sat, Oct 7, 2017 at 10:07 AM, James Valaitis via swift-evolution <
swift-evolution@swift.org> wrote:
> Is it widely agreed that it is necessary to requ
This has been brought up on the list before. For instance:
https://github.com/apple/swift-evolution/pull/608
Chris Lattner’s response at that time was:
‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
that fits the goal of Swift 4 stage 2.
‘I’m also pretty opposed to do
One argument: without this fix, private is the only access level for which we
have no means to easily and implicitly apply an access level to a group of
members. And it bums me to have to explicitly type private on ever single
member to achieve the same result as I can with any other access leve
This, I think, is the most persuasive argument available here; it provides
a concrete use case to justify why one design is superior to the other.
On Sat, Oct 7, 2017 at 10:26 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:
> One argument: without this fix, private is the only a
For what it's worth, you can drop the "get" part for read-only computed
properties and write:
var session: AVCaptureSession { return layer.session }
On Sat, Oct 7, 2017 at 7:07 AM James Valaitis via swift-evolution <
swift-evolution@swift.org> wrote:
> Is it widely agreed that it is necessa
On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu wrote:
> This has been brought up on the list before. For instance:
>
> https://github.com/apple/swift-evolution/pull/608
>
> Chris Lattner’s response at that time was:
>
> ‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
> that
Two weeks ago I had a fairly strong opinion about “private extension”
behavior. After following this discussion, I now have no opinion on the
matter.
I would summarize the points on both sides as follows:
For the change:
• It is surprising to many people that members of a private extension are
im
> On Oct 7, 2017, at 8:28 AM, Xiaodi Wu wrote:
>
> This, I think, is the most persuasive argument available here; it provides a
> concrete use case to justify why one design is superior to the other.
open extension do not exist either. :)
>> On Sat, Oct 7, 2017 at 10:26 David Hart via swift-
I think the important thing to consider is, what advantage would such a
feature provide *other* than to reduce keystrokes? (I don't personally
think that optimizing for keys pressed by itself should be a goal.)
In the case of closures, single expression closures without "return"
improve readabilit
On Sat, Oct 7, 2017 at 12:21 Jose Cheyo Jimenez wrote:
>
>
> On Oct 7, 2017, at 8:28 AM, Xiaodi Wu wrote:
>
> This, I think, is the most persuasive argument available here; it provides
> a concrete use case to justify why one design is superior to the other.
>
>
> open extension do not exist eit
> On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution
> wrote:
>
> Two weeks ago I had a fairly strong opinion about “private extension”
> behavior. After following this discussion, I now have no opinion on the
> matter.
>
> I would summarize the points on both sides as
> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution
> wrote:
>
> While working on the non-exhaustive enums proposal I had it pointed out to me
> that structs actually currently leak implementation details across module
> boundaries, specifically their full set of stored properties.
> On Oct 5, 2017, at 9:32 AM, Joe Groff wrote:
>
>>>
>>> The suggestion to have this semantics was originally my fault, I believe,
>>> and it arose from the observation that if we have 'inlinable' backed by a
>>> symbol in the binary, then we'd also want the 'must be emitted by client'
>>> a
On Oct 5, 2017, at 1:30 PM, Joe Groff wrote:
>> On Oct 4, 2017, at 9:24 PM, Chris Lattner wrote:
>> On Oct 4, 2017, at 9:44 AM, Joe Groff wrote:
I disagree. The semantics being proposed perfectly overlap with the
transitional plan for overlays (which matters for the next few years),
Has there been any progress on this? I came here to propose this but came upon
this thread first.
This proposal goes way beyond sugar. I find myself constantly in the following
situation:
let observer = Observer(with: CircuitBreaker(holding: self))
do {
let handlerDi
> try startHandler(observer) catch {
> observer.sendFailed(error)
> }
Technically the above doesn’t make sense. Please disregard.
> On Oct 7, 2017, at 10:35 PM, Tyler Cloutier wrote:
>
> Has there been any progress on this? I came here to propose this but came
> upon this thread first.
>
Also the Scala approach already works quite nicely in Swift 4 in case anyone
was curious:
enum Try {
case success(T)
case failure(Error)
init(_ f: @autoclosure () throws -> T) {
do {
self = .success(try f())
} catch {
self = .failure(error)
Oh look, a Result! Yes, this is a very useful type that should be part of the
base language. Both guard / catch and Result would be great for Swift’s error
handling.
Jon
> On Oct 8, 2017, at 2:01 AM, Tyler Cloutier via swift-evolution
> wrote:
>
> Also the Scala approach already works quit
19 matches
Mail list logo
