Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and
static function properties in appropriate protocol conformance scenarios:
Would love any feedback or edge cases I may have missed!
···
--
@jasdev
I only had a passing glance but I'm a fan.
···
On 11 Jul. 2016, at 6:33 am, Jasdev Singh via swift-evolution <swift-evolution@swift.org> wrote:
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:
Would love any feedback or edge cases I may have missed!
--
@jasdev
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Hi Jasdev,
I wanted this once, before Swift 1 was released. Its lack was easy to
work around and I have never wanted it since, so... I'm afraid I don't
think it is worth complicating the language for. Your proposal shows
how the feature *can be used*, but doesn't make a compelling case that it
*will be very useful*. That's what would be needed to convince me.
HTH,
···
on Sun Jul 10 2016, Jasdev Singh <swift-evolution@swift.org> wrote:
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and
static function properties in appropriate protocol conformance scenarios:Would love any feedback or edge cases I may have missed!
--
Dave
This is an additive proposal, thus out of scope for Swift 3.
Beyond that, as someone downthread mentioned, the major thing missing here is a strong motivation for *why* we should do this. You say only "we see that the protocol requirements and conformances are actually equivalent and should both be valid.” but adding redundant ways to say the same thing motivation.
-Chris
···
On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution <swift-evolution@swift.org> wrote:
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:
Would love any feedback or edge cases I may have missed!
I meant: "but adding redundant ways to say the same thing is not a motivation.”
-Chris
···
On Jul 11, 2016, at 3:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:
Would love any feedback or edge cases I may have missed!
This is an additive proposal, thus out of scope for Swift 3.
Beyond that, as someone downthread mentioned, the major thing missing here is a strong motivation for *why* we should do this. You say only "we see that the protocol requirements and conformances are actually equivalent and should both be valid.” but adding redundant ways to say the same thing motivation.
Regards
(From mobile)
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and
static function properties in appropriate protocol conformance scenarios:Would love any feedback or edge cases I may have missed!
Hi Jasdev,
I wanted this once, before Swift 1 was released. Its lack was easy to
work around and I have never wanted it since, so... I'm afraid I don't
think it is worth complicating the language for. Your proposal shows
how the feature *can be used*, but doesn't make a compelling case that it
*will be very useful*. That's what would be needed to convince me.
Have you looked into the design patterns it opens the door to, or how it is used in languages where it is present? IME it has to do with higher degrees of abstractions or more dynamic behaviors. Granted it is also not the only way to achieve that. TypeScript might interest you if you have not yet looked into it closely.
···
On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sun Jul 10 2016, Jasdev Singh <swift-evolution@swift.org> wrote:
HTH,
--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Regards
(From mobile)Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions and
static function properties in appropriate protocol conformance scenarios:Would love any feedback or edge cases I may have missed!
Hi Jasdev,
I wanted this once, before Swift 1 was released. Its lack was easy to
work around and I have never wanted it since, so... I'm afraid I don't
think it is worth complicating the language for. Your proposal shows
how the feature *can be used*, but doesn't make a compelling case that it
*will be very useful*. That's what would be needed to convince me.Have you looked into the design patterns it opens the door to, or how
it is used in languages where it is present? IME it has to do with
higher degrees of abstractions or more dynamic behaviors.
Right, the latter.
Granted it is also not the only way to achieve that.
Right. It's also not the most efficient way in most cases. It's better
to store one class instance than a bunch of closures.
TypeScript might interest you if you have not yet looked into it
closely.
Thanks, but the onus is on the proposer to make a case for his feature.
I'm trying to explain how to do that.
···
on Mon Jul 11 2016, "L. Mihalkovic" <laurent.mihalkovic-AT-gmail.com> wrote:
On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sun Jul 10 2016, Jasdev Singh <swift-evolution@swift.org> wrote:
--
Dave
Hey Chris, thanks so much for the feedback!
This is an additive proposal, thus out of scope for Swift 3.
For sure! Definitely didn’t expect this to land pre-3.0 :)
Beyond that, as someone down thread mentioned, the major thing missing
here is a strong motivation for *why* we should do this.
I should’ve added more color to the motivation. The idea for this proposal
sparked from a conversation w/ Joe Groff
<https://twitter.com/jasdev/status/751875707375120385>
<https://twitter.com/jasdev/status/751875707375120385>
https://twitter.com/jasdev/status/751875707375120385
<https://twitter.com/jasdev/status/751875816896786432>
https://twitter.com/jasdev/status/751875816896786432
I was attempting to use rdar://19091028 as a way to create protocol that
can be shared across enums to guarantee the presence of a specific case.
For example, imagine we wanted a series of enumerations that could wrap an
`NSError` like so
This could be helpful when returning a `Result` from a function that has an
intermediary step that could throw an `NSError`. With such an ability, we
could keep the functions return type to be `Result<T, SomeOtherError>` for
some `T` (and `SomeOtherError` from the gist mentioned before) w/o having
to make the returned error less specific (i.e. a plain `NSError`).
Hope this adds some clarity!
···
On Mon, Jul 11, 2016 at 6:43 PM Chris Lattner <clattner@apple.com> wrote:
On Jul 11, 2016, at 3:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
On Jul 10, 2016, at 1:33 PM, Jasdev Singh via swift-evolution < > swift-evolution@swift.org> wrote:
Hey Swift Evolution!
Drafted up a small proposal that harmonizes the use of static functions
and static function properties in appropriate protocol conformance
scenarios:Would love any feedback or edge cases I may have missed!
This is an additive proposal, thus out of scope for Swift 3.
Beyond that, as someone downthread mentioned, the major thing missing here
is a strong motivation for *why* we should do this. You say only "we see
that the protocol requirements and conformances are actually equivalent and
should both be valid.” but adding redundant ways to say the same thing
motivation.I meant: "but adding redundant ways to say the same thing is not a
motivation.”-Chris
--