Type::T...itfield(3)

πŸ’– Type::Tiny::Bitfield β€” the manual, but make it cute πŸ’–

okay so bestie, you know how a bitfield is just a bunch of flags squished into one integer? yeah. this module, Type::Tiny::Bitfield (from the User Contributed Perl Documentation, iykyk), gives you ✨type constraints✨ for exactly that. bitfield / bitflag type constraints, no cap. let's get into it πŸ¦‹


✨ NAME ✨

Type::Tiny::Bitfield β€” bitfield/bitflag type constraints. that's the whole vibe. periodt.


🌸 SYNOPSIS 🌸

okay there's two ways to do this and both are lowkey iconic.

the export feature (main character energy)

package LightSource {
  use Moo;

  use Type::Tiny::Bitfield LedSet => {
    RED   => 1,
    GREEN => 2,
    BLUE  => 4,
  };

  has leds => ( is => 'ro', isa => LedSet, default => 0, coerce => 1 );

  sub new_red {
    my $class = shift;
    return $class->new( leds => LEDSET_RED );
  }

  sub new_green {
    my $class = shift;
    return $class->new( leds => LEDSET_GREEN );
  }

  sub new_yellow {
    my $class = shift;
    return $class->new( leds => LEDSET_RED | LEDSET_GREEN );
  }
}

look at those bitwise ORs bestie. LEDSET_RED | LEDSET_GREEN = yellow. the math is mathing πŸ’…

the object-oriented interface

package LightSource {
  use Moo;
  use Type::Tiny::Bitfield;

  my $LedSet = Type::Tiny::Bitfield->new(
    name   => 'LedSet',
    values => {
      RED   => 1,
      GREEN => 2,
      BLUE  => 4,
    },
    coercion => 1,
  );

  has leds => ( is => 'ro', isa => $LedSet, default => 0, coerce => 1 );

  sub new_red {
    my $class = shift;
    return $class->new( leds => $LedSet->RED );
  }

  sub new_green {
    my $class = shift;
    return $class->new( leds => $LedSet->GREEN );
  }

  sub new_yellow {
    my $class = shift;
    return $class->new( leds => $LedSet->coerce('red|green') );
  }
}

see how the OO one just does $LedSet->coerce('red|green')?? she's flexible, she's chic, she's stringy. obsessed 😭✨


πŸ‘‘ STATUS πŸ‘‘

ngl this module is covered by the Type-Tiny stability policy. it's stable, it's secure, it's not going anywhere. 🫢


πŸŽ€ DESCRIPTION πŸŽ€

Bitfield type constraints. that's the one-liner. that's it.

this package inherits from Type::Tiny β€” go read that one for most of the documentation, she's the blueprint. the major differences are listed below, and yes we're going through every single one πŸ’–

🧚 Attributes

  • values β€” a hashref of the bits allowed in the bitfield. the keys must be UPPER_SNAKE_CASE strings, no exceptions. the values must be positive integers which are powers of two. and bestie, listen: the same number cannot be used multiple times. that's a hard no. πŸ’€
  • constraint β€” unlike Type::Tiny, you cannot pass a constraint coderef to the constructor. nope. not allowed. just rely on the default, she's got it. πŸŽ€
  • inlined β€” same deal, unlike Type::Tiny, you cannot pass an inlining coderef to the constructor. rely on the default, bestie. the default ate. πŸ”₯
  • parent β€” parent is always Types::Common::Numeric::PositiveOrZeroInt, and it cannot be passed to the constructor. it's set, it's locked, it's the moment. πŸ‘‘
  • coercion β€” if you pass coercion => 1 to the constructor, the type gets an automatic coercion from Str. and types built by the import method will always have coercion => 1, no opting out, it's just the rules. πŸ¦‹

in the SYNOPSIS example, the coercion from Str will accept strings like:

"RED"
"red"
"Red Green"
"Red+Blue"
"blue | GREEN"
"LEDSET_RED + LeDsEt_green"

the case-insensitivity?? the spaces?? the plus signs AND pipes?? she's giving tolerant. we love a type that doesn't nitpick. πŸ’…

🌈 Methods

this class uses AUTOLOAD to let you use the name of each bit in the bitfield as a method. so the method names will always be UPPER_SNAKE_CASE. that's the law. πŸŽ€

for example, in the synopsis, LedSet->GREEN would return 2. cute, right?

other methods it provides:

  • from_string( $str ) β€” provides the standard coercion from a string, even if this type constraint doesn't have a coercion. so even un-coerced types can still pull this move. iconic. ✨
  • to_string( $int ) β€” does the reverse coercion. the other direction. the mirror. πŸ¦‹
  • constant_names() β€” this is a convenience to allow for:
use base 'Exporter::Tiny';
push our @EXPORT_OK, LineStyle->constant_names;

handing you the names so you don't have to type them out. a gift, honestly. 🫢

πŸ’œ Exports

Type::Tiny::Bitfield can be used as an exporter. like this:

use Type::Tiny::Bitfield LedSet => {
  RED    => 1,
  GREEN  => 2,
  BLUE   => 4,
};

and this will export the following functions into your namespace:

  • "LedSet"
  • is_LedSet( $value )
  • assert_LedSet( $value )
  • to_LedSet( $string )
  • LedSet_to_Str( $value )
  • "LEDSET_RED"
  • "LEDSET_GREEN"
  • "LEDSET_BLUE"

look at all of them. a whole little family. πŸ₯Ή

multiple bitfield types can be exported at once, too:

use Type::Tiny::Enum (
  LedSet     => { RED => 1, GREEN => 2, BLUE => 4 },
  LedPattern => { FLASHING => 1 },
);

two types, one use statement. efficiency queen. πŸ’…

⭐ Overloading

it is possible to combine two Bitfield types using the "+" operator. yes, literally the plus sign. we're doing bitfield math in the type system now. πŸ”₯

use Type::Tiny::Enum (
  LedSet     => { RED => 1, GREEN => 2, BLUE => 4 },
  LedPattern => { FLASHING => 8 },
);

has leds => (
  is      => 'ro',
  isa     => LedSet + LedPattern,
  default => 0,
  coerce  => 1
);

this will allow values like "11" (LEDSET_RED|LEDSET_GREEN|LEDPATTERN_FLASHING). do the math, bestie: 1 + 2 + 8 = 11. it checks out. πŸ‘‘

⚠️ an exception will be thrown if any of the names in the two types being combined conflict. so like, don't name two bits the same thing and then try to mash them together. that's a no. πŸ’€

πŸ™ˆ BUGS πŸ™ˆ

please report any bugs to <https://github.com/tobyink/p5-type-tiny/issues>. fr fr, he wants to know. don't be shy. 🫢


🌸 SEE ALSO 🌸

  • Type::Tiny::Manual.
  • Type::Tiny.

go read them. they're the prerequisites, the lore, the extended universe. πŸ“šβœ¨


πŸ’– AUTHOR πŸ’–

Toby Inkster <tobyink@cpan.org>.

the man, the myth, the legend. the one who wrote all these modules so we could have nice things. πŸ‘‘


this software is copyright (c) 2023-2025 by Toby Inkster.

this is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. so like, go wild, but respectfully. πŸ’…


πŸ¦‹ DISCLAIMER OF WARRANTIES πŸ¦‹

THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

translation: she comes with no guarantees. no warranty. none. if it breaks, that's on you bestie 😭 (but also it's stable, per the STATUS section, so like. it probably won't.)


and that's the whole page!! written for perl v5.42.0, dated 2026-01-17, straight out of the User Contributed Perl Documentation ✨ go forth and bitfield, bestie πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from