Skip to content

[stdlib] Use VariadicPack instead of VariadicList where possible#6369

Draft
martinvuyk wants to merge 1 commit intomodular:mainfrom
martinvuyk:use-variadicpack
Draft

[stdlib] Use VariadicPack instead of VariadicList where possible#6369
martinvuyk wants to merge 1 commit intomodular:mainfrom
martinvuyk:use-variadicpack

Conversation

@martinvuyk
Copy link
Copy Markdown
Contributor

Use VariadicPack instead of VariadicList where possible. #6356 remains blocked in another PR, these here should work with no issues

@github-actions github-actions Bot added mojo-stdlib Tag for issues related to standard library waiting-on-review labels Apr 6, 2026
@martinvuyk martinvuyk force-pushed the use-variadicpack branch 18 times, most recently from d59c519 to 61406e5 Compare April 7, 2026 17:58
Signed-off-by: martinvuyk <martin.vuyklop@gmail.com>
@martinvuyk
Copy link
Copy Markdown
Contributor Author

Blocked by #6381

@lsh
Copy link
Copy Markdown
Contributor

lsh commented Apr 15, 2026

I'd like to see a more detailed motivation for this change.

def __init__(out self, var *elems: Self.ElementType, __list_literal__: ()):
def __init__[
*Ts: type_of(Self.ElementType)
](out self, var *elems: *Ts, __list_literal__: ()) where (
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is almost certainly not correct. An InlineArray takes a homogenous type.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

it does, as an example *Ts: type_of(Int) enforces a single type

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If the goal is to try and optimize InlineArray using this information, I think the better solution is to have __list_literal__ carry an actual size parameter, but I can be convinced otherwise.

Copy link
Copy Markdown
Contributor Author

@martinvuyk martinvuyk Apr 15, 2026

Choose a reason for hiding this comment

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

It's not about optimization but enforcing a compile-time known constraint at compile time

# FIXME: this used to be simpler
# var vb = Int(to_int(b))
var vb = RuntimeTuple[IntTuple(UNKNOWN_VALUE)](Int(b))
comptime R = RuntimeTuple[IntTuple(UNKNOWN_VALUE)]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm strongly -1 on these single letter aliases.

def __init__[
*Ts: type_of(String)
](
out self: InlineArray[StaticString, Self.size],
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We're moving away from custom Self types in favor of where clauses, so this is not ideal.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yeah I don't know what is going on with the compiler but it eagerly lowers StringLiteral into String so anything wanting to construct InlineArray[StaticString, 1] = ["asd"] where the constructor expects the initializer type to equal the target type it would fail. We currently don't have a nice way for variadic packs to properly take implicit type conversion into account (#6357) and also carries type information incorrectly (#6381)

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

Labels

mojo-stdlib Tag for issues related to standard library waiting-on-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants