Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13325] No way to express conditional differentiability of function parameters based on that of generic parameter #55765

Open
dabrahams opened this issue Jul 30, 2020 · 5 comments
Labels
AutoDiff bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@dabrahams
Copy link
Collaborator

Previous ID SR-13325
Radar None
Original Reporter @dabrahams
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Swift for TensorFlow
Labels Bug, AutoDiff
Assignee None
Priority Medium

md5: 2bdd7e64a6b7e0424705c091ca000b07

Issue Description:

This method won't compile:

  /// Calls `updateElement(&myX, aX)` on each pair of corresponding elements `myX` and `aX` of
  /// `self` and `a`, using `combine` (if supplied) to initialize new storage when required.
  ///
  /// - Requires: `self.count == a.count`
  @differentiable(wrt: (self, a) where Element: Differentiable, E: Differentiable)
  mutating func update<E>(
    elementwiseWith a: ArrayBuffer<E>,
    _ updateElement: @differentiable (_ myX: inout Element, _ aX: E)->Void,
    _ combine: Optional<@differentiable (_ a0x: Element, _ a1x: E)->Element> = nil
  ) { fatalError() }

The fundamental limitation is that we have no way to say thats updateElement and combine are @differentiable(where: Element: Differentiable, E: Differentiable) (that's a syntax error).

@rxwei
Copy link
Member

rxwei commented Jul 30, 2020

This is a limitation of the @differentiable function type attribute. Supporting a where-clause within a function type attribute may involve a non-trivial implementation given that there's no precedence of function type attributes containing generic constraints and because @differentiable/@differentiable(linear) is currently just a two-bit flag in AnyFunctionType::ExtInfo. Besides the potential implementation difficulty, function types with such constraints could be long and difficult to read:

@differentiable(where Element: Differentiable, E: Differentiable) (_ myX: inout Element, _ aX: E) -> Void

Have you tried defining additional update(elementwiseWith::🙂 overloads with more specific generic requirements such that the most specific one will win in overload resolution? What's the specific use case of this method?

@theblixguy
Copy link
Collaborator

@rxwei @_specialize supports where clauses so it should be possible to extract some code and reuse here, if you decide to go with this.

@rxwei
Copy link
Member

rxwei commented Jul 30, 2020

@theblixguy If I remember correctly, @_specialize is a DeclAttr. And we did port @_specialize's support for where-clauses to the @differentiable declaration attribute, but this issue in this radar is mainly about the @differentiable function type attribute like @convention. Are you saying there also exists a @_specialize function type attribute today?

@theblixguy
Copy link
Collaborator

Oh, I see. Sorry, I overlooked the “function type” bit. I don’t think we have any function type attributes with where clauses at the moment. I suppose it should still be relatively straightforward to parse the where clause in such a context (with possibility to share code) but I haven’t given it much thought.

@rxwei
Copy link
Member

rxwei commented Jul 31, 2020

@theblixguy Thanks for the pointer!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AutoDiff bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

No branches or pull requests

4 participants