<Tetralux>
Or rather, `comptime by_pointer: bool`.
<Tetralux>
The idea of using *e to mean "I can remove this elem", is an interesting idea.
<Tetralux>
Though, it's a little strange because that's talking about "can I modify the elem in the iterable?" rather than "can I remove it from the iterable?"
<Tetralux>
Mutability of the value, rather than mutability of existence.
<mikdusan>
to be clear i'm bring this up in regards to mutating an item, **not** mutating the list size
<mikdusan>
i'll try to make time to reply to your PR. thanks for answering
<Tetralux>
Oh, you mean, for instance, "I'm iterating over this iterable thing; if I find an element of a certain value, I want to update it."
<Tetralux>
And I'd appreciate responses, so feel free :)
<mikdusan>
(yes to the Q).
<Tetralux>
AH
<fengb>
In current for loops, without the * implies “const”, like function args
<Tetralux>
I don't see why that would be a problem. :3
<Tetralux>
It may be for all I know, but I can't think of a reason rn.
<mikdusan>
take a simple primitive like u32. compiler can pass by value for const iteration. for non-const it must use an underlying pointer for reference semantics.
<mikdusan>
that sounds to me like iterator() has 2 different code paths
<Tetralux>
It's comptime known which you take.
<mikdusan>
what i mean is if i have the same program... that iterates one place as const, another place as non-const... i need 2 versions of iterate()
<Tetralux>
Yeah, that seems fair.
<mikdusan>
i guess no big deal if it's generated by compiler. just wanted to suss this out and make sure the programmer doesn't need to define 2 functions.
<mikdusan>
i think you're correct, programmer only needs 1. i was getting confused programmer vs. compiler
<Tetralux>
Oh no - the programmer would _definitely_ not need to define two functions.
<Tetralux>
If they did, I'd consider it a failure xD
<Tetralux>
That would be quite silly.
<Tetralux>
Unless there's a good reason I'm not thinking of.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<Mr_Slurpy>
just fyi, you might already know this but "zig translate-c" seg faults when you pass it a file that doesn't exist
<Mr_Slurpy>
Confused me at first lol
<mikdusan>
also 0-byte file
sammich has quit [*.net *.split]
_whitelogger has joined #zig
hoppetosse has joined #zig
<andrewrk>
FireFox317, the logger is back
<Tetralux>
It does pass, yeah :)
<andrewrk>
but does it work with a new test case that has your new align syntax
<Tetralux>
*coughs*
<Tetralux>
ONE MOMENT
<andrewrk>
that will test parsing and rendering both, if you add a testCanonical
<Tetralux>
Add a 'test {}' to align.zig?
<Tetralux>
Where does the testCanonical go?
<andrewrk>
../std/zig/parser_test.zig
<andrewrk>
these test the stage2 parser and renderer
<Tetralux>
Added such a test to parse_test.zig; it fails.
<Tetralux>
It doesn't render the align(N).
<andrewrk>
unless you edited std/zig/parse.zig I would expect parsing to fail as well
<Tetralux>
I did edit it ;)
<andrewrk>
rendering code is in std/zig/render.zig
<Tetralux>
I'm having trouble figuring out how to get the align expression from the tree so I can render it.
<andrewrk>
you might find inspiration from where the other align() syntax is rendered
<andrewrk>
for pointer types
<Tetralux>
I can't even find that xD
<Tetralux>
Ah wait - I think I just found it.
<Tetralux>
When I edited parse.zig, I put the align_expr on ContainerField.
<Tetralux>
Ah yes - foudn it.
<Tetralux>
Man this is awkward to get your head round.
<Tetralux>
Slowly figuring it out though
<gonz_>
Is "{d:<32.3}" in a format string not supposed to be 32 characters wide left-aligned float with 3 decimals precision?
<gonz_>
Getting the fill/alignment to make any difference at all seems a challenge.
<andrewrk>
I think tiehuis either just changed that or is in the middle of changing it