You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would be nice to be able to specify a bitflag literal, where the bitflag is derived from an enum.
This would be useful, for example, when specifying opcode modes for inline assembly. Currently the (asm) builtin takes a string, e.g. (asm "gr" .Op/Oadd), which would be more consistent as an enum. Defining an enum to carry all possible variations of the flags (grk, gkr, srk, k, kr, etc) would be tedious, though, which is where flags would help.
This could be done with a (flags) builtin: (flags <type> <enum literals>...). No compile-time checking would be done on the enum to ensure it makes sense to use it in that context, that would be the user's responsibility.
Example:
(asm (flags OpFl g r k) .Op/Opop)
(asm (flags OpFl s r) .Op/Osub)
(asm .OpFl/g .Op/Oadd) // Single flag would just be the enum literal itself
To be more concise, perhaps (| ...) could be used instead:
(asm (| OpFl g r k) .Op/Opop)
(asm (| OpFl s r) .Op/Osub)
Or if we really wanted to be concise, just drop the idea of adding a builtin and add a dedicated syntax instead:
Would be nice to be able to specify a bitflag literal, where the bitflag is derived from an enum.
This would be useful, for example, when specifying opcode modes for inline assembly. Currently the
(asm)
builtin takes a string, e.g.(asm "gr" .Op/Oadd)
, which would be more consistent as an enum. Defining an enum to carry all possible variations of the flags (grk
,gkr
,srk
,k
,kr
, etc) would be tedious, though, which is where flags would help.This could be done with a
(flags)
builtin:(flags <type> <enum literals>...)
. No compile-time checking would be done on the enum to ensure it makes sense to use it in that context, that would be the user's responsibility.Example:
To be more concise, perhaps
(| ...)
could be used instead:Or if we really wanted to be concise, just drop the idea of adding a builtin and add a dedicated syntax instead:
Though I don't really like the idea of adding yet more symbol soup to the language -- it already has quite enough in my opinion.
The text was updated successfully, but these errors were encountered: