@enforce_keys and Kernel.struct

RobertDober

First of all

Happy New Year everyone

Disclaimer I did not find an issue on Github or a discussion here on this topic, if I missed it, my appologies

one of my resolutions have been to work on EarmarkParser, … again and during my refactorings I stumbled about a puzzling behavior

defmodule LP2.Parser.ListInfo do                                                                                                                                                                      
  use LP2.Types                                                                                                                                                                                       
                                                                                                                                                                                                      
  @enforce_keys [:bullet, :list_indent, :loose]                                                                                                                                                       
  defstruct bullet: nil, list_indent: nil, loose: false                                                                                                                                               
                                                                                                                                                                                                      
  @type t :: %__MODULE__{bullet: binary(), list_indent: non_neg_integer(), loose: boolean()}                                                                                                                                                                                                                                                   
end

please note the @enforce_keys, I verified that that works and then found, quite puzzled, that it does not

iex(1)> alias LP2.Parser.ListInfo
LP2.Parser.ListInfo
iex(2)> struct(ListInfo)
%LP2.Parser.ListInfo{bullet: nil, list_indent: nil, loose: false}

then I tried this

 iex(3)> %ListInfo{}
** (ArgumentError) the following keys must also be given when building struct LP2.Parser.ListInfo: [:bullet, :list_indent, :loose]
    (lp2 0.1.0) expanding struct: LP2.Parser.ListInfo.__struct__/1
    iex:3: (file)

which is good, of course, now my questions are

is the usage of struct discouraged?
if not, should the behavior of ignoring @enforce_keys not be considered as a bug?

KR
Robert

5 comments

#question

0 2900 5

2021-01-05 09:14:03 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

Nicd

Seems there is an exclamation point version that does check @enforce_keys: Kernel — Elixir v1.20.2

Post #1

RobertDober

oops, great than, sorry for the noise

Post #2

al2o3cr

“Discouraged” is probably too strong, but I’d generally suggest a different approach if you’re passing a compile-time constant for the struct name - generic libraries like Ecto have to use a function like struct, but it makes it harder for the compiler to catch errors.

For instance:

defmodule Demo do
  @enforce_keys [:required_thing]
  defstruct [:name, :required_thing]
end

# compile-time error
%Demo{naem: "oops"}

# run-time error
struct!(Demo, %{naem: "oops"})

# no error
struct(Demo, %{naem: "oops"})

Similarly, AFAIK Dialyzer can’t “see” through struct calls, so it’s possible to produce code that breaks the @type defined in the struct.

Also beware that “enforced keys” means precisely that - the key is present in the input:

iex(1)> defmodule Demo do
...(1)>   @enforce_keys [:name]
...(1)>   defstruct [:name]
...(1)> end
{:module, Demo,
 <<70, 79, 82, 49, 0, 0, 9, 152, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 1, 29,
   0, 0, 0, 28, 11, 69, 108, 105, 120, 105, 114, 46, 68, 101, 109, 111, 8, 95,
   95, 105, 110, 102, 111, 95, 95, 10, 97, ...>>, %Demo{name: nil}}
iex(2)> struct!(Demo, %{name: nil})
%Demo{name: nil}

Post #3

Qqwy

TypeCheck Core Team

Exactly this. struct is vital in certain complex macros where it might not be always possible to compile the struct-module before the macro-module.
In normal code, however, we really do want the struct module to be compiled first, exactly because (a) then it is possible to perform an @enforce_keys-check and (b) preventing cyclic dependencies in general is a good idea for maintainability.

Post #4

RobertDober

yes very well put, I changed all my occurrences of struct to struct! after the first reply.

I wonder if I should make a PR for the doc of Kernel.struct underlining the dangers of struct a little bit better?

Do you feel that the current documentation transpires the points you have made?

which can be found here

Post #5

— All posts loaded —

Where Next?

View thread on forum (has 5 replies!)

question

Home Chat & Discussions>Discussions

8 2588 5

Last post

REPLY VIEW THREAD WITH 5 POSTS

@enforce_keys and Kernel.struct

RobertDober

Happy New Year everyone

Showing Posts 1 to 5 Show Best PostsShow All (oldest first)Show All (newest first)

Nicd

RobertDober

al2o3cr

Qqwy

RobertDober

Where Next?

Trending in Discussions

Stack Overflow Developer Survey 2026

Remote Elixir Book Club (takes place on Discord)

How does Elixir keep going?

What IDE/Editor do you use for Elixir?

Now that fly are pivoting, should I trust them for hosting?

Thoughts on “Evolving programming languages in the AI era”?

Deploying Phoenix/Elixir to UpCloud - 2026 advice?

Other Trending Topics

State of developing agents with Elixir (not coding agents)

Yoke - the DeepSeek Harness (former DSH)

Beam Bots - Resilient Robotics on the BEAM

Emily - A new MLX-based backend for Nx

Why AI dream is a non sense and will die

Tempo - a unified time type that models time as interval sets, not instants

Chat & Discussions>Discussions

Latest on Elixir Forum

Sponsor Spotlight

Our Sponsors

Categories:

Sub Categories:

Forums

Popular Tags

Our Sponsors

We're in Beta

Options

Thread Display Mode

Thread Preview

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)