Skip to content

Conversation

@AppAppWorks
Copy link
Contributor

@AppAppWorks AppAppWorks commented Oct 24, 2025

fixes #286

The blast radius was larger than I expected, I ended up implementing the following changes:

  • replaced the use of concrete arrays with some Collection and some Sequence, whenever applicable
  • replaced the use of existentials with generics

Some type checking ambiguities arose after the changes, I have to do the following to break ties:

  • removed the default argument for dtype: from functions which have a type: T.Type = <default> overload

I've avoided overridable methods to maintain source compatibility

@AppAppWorks AppAppWorks marked this pull request as draft October 24, 2025 04:37
@AppAppWorks AppAppWorks force-pushed the genericize-function-arguments branch from bf09b58 to d2c67ef Compare October 24, 2025 04:41
/// - ``ones(_:type:stream:)``
static public func zeros(
_ shape: [Int], dtype: DType = .float32, stream: StreamOrDevice = .default
_ shape: some Collection<Int>, dtype: DType, stream: StreamOrDevice = .default
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how this wasn't ambiguous before? Maybe it was and it just picked one (since they have the same defaults)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know either, I've come across with this issue a lot when I genericized my codebases. Maybe due to some type-checker quirks.
I think removing these default arguments won't break the call sites. We might, however, bikeshed on whether to remove these from type: or dtype:.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it will break callers, but we can try it out with mlx-swift-examples and see if anything shows up.

Copy link
Collaborator

@davidkoski davidkoski Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested the current branch with mlx-swift-examples and everything built cleanly.

@AppAppWorks AppAppWorks force-pushed the genericize-function-arguments branch 2 times, most recently from 7c306ae to 1ef6091 Compare October 24, 2025 22:44
- replaced the use of concrete arrays with Collection and Sequence, when applicable
- replaced the use of existentials with generics
- removed the default arguments for `dtype:` to resolve the ambiguities arisen after the changes
@AppAppWorks AppAppWorks force-pushed the genericize-function-arguments branch from 1ef6091 to b03d202 Compare October 24, 2025 23:07
@AppAppWorks
Copy link
Contributor Author

One unintended consequence of this PR is it has broken a lot of docc function hashes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Functions should take generic collection types instead of concrete types as arguments

2 participants