@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 2705 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

What Elixir related stuff are you doing?

Phoenix Storybook: a storybook-like UI interface for Phoenix components

Cure - a new language compiled to BEAM

Ergo - a framework for creating microservices using technologies and design patterns of Erlang/OTP in Golang

BEAM Chat/News

Security advisory: Decimal DoS vulnerability

What IDE/Editor do you use for Elixir?

Other Trending Topics

Gust - A task orchestration system built in Elixir

Beam Bots - Resilient Robotics on the BEAM

Xamal - Deploy Elixir releases to bare metal servers via SSH

Corex - Accessible and unstyled UI Phoenix components

How much do you still code yourself?

Aludel - LLM prompt evaluation workbench

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)