Why can you remove fields from defstructs's maps if you can't add them?

Questions / Help
1

I was just going through some stuff with some jr. devs about how structs work, and we were fooling around with what can be done with them as an exercise, and then… well. We struct (lol) something I wasn’t able to explain away. Assume:

defmodule Cat do
  defstruct type: nil, weight: nil
end

Obviously, %Cat{variance: "tabby"} fails with keyerror, because variance doesn’t exist on the struct, and if you did go %Cat{}, you’d receive %Cat{type: nil, weight: nil}… And further if you try to go with

%{%Cat{} | variance: "tabby"}

again, it checks that you can’t add something that was defined. You get some semblence of safety when it comes to the values of what you can expect on a struct. On defined Cat struct, it’d contain the values of type and `weight.

But… Map.delete(%Cat{type: "Maine Coon"}, :weight) gives you the appearance of a valid(?) struct still.

%{__struct__: Cat, type: "Maine Coon"}

At no point does it give the indication that it’s out of step with the struct and I haven’t been able to find out how to validate that. I’d expect on create time we’d handle the checks, but when modifying post-create, there’s no integrity checks here. I thought that maybe Kernel.struct/2 might be a use to validate here, but it comes out clean.

Obviously this is a much smaller issue when you’re using Ecto and changesets, but it was something that really quirked me a bit! TIA for the explaination.

2

Structs are only maps underneath, with some compiler guarantees. In this case, the compiler cannot infer that the deletion should not happen, so it cannot warn about it. In theory the Map.delete function could check if the given map has a :__struct__ key at runtime, but currently it doesn’t do that (and I don’t think it will be changed).

3 Likes
3

The fact that you can see the :__struct__ key in the inspect output is meant to warn you that you no longer have a valid %Cat{} struct.

You get a similar error if you add a non-existant key to a struct directly with Map.put:

iex> Map.put(cat, :some_bad_key, "val")
%{__struct__: Cat, some_bad_key: "val"}
5 Likes
4

Okay this makes a bit more sense here! But then…

iex> %Cat{type: "Maine Coon"}.__struct__                           
Cat
iex> %Cat{type: "Maine Coon"}                                      
%Cat{type: "Maine Coon", weight: nil}

It’s not present in the output, and obviously that’s the namespacing, but if you tried to pattern match on it, you’d ultimately find that __struct__ matched correctly right? Like

iex> %{__struct__: Cat} = %Cat{type: "Maine Coon"}
%Cat{type: "Maine Coon", weight: nil}

And just for thoroughness, we’d expect that

iex> %{__struct__: Cat, variance: "Tabby"} = %Cat{type: "Maine Coon"}
** (MatchError) no match of right hand side value: %Cat{type: "Maine Coon", weight: nil}

Which you’d expect because you’re ultimately trying to initialize a __struct__: Cat.

So, we can validate visually by the output, but how would you do that programatticaly in this case?

5

Just don’t break the structs, Elixir is a dynamic language and requires some countenance.

2 Likes
6

It’s present, that’s how inspect knows to format it as %Cat{...} instead of %{...}.

You can even write code that matches on __struct__:

def thing_that_captures_struct(%struct_var{} = input) do
  # if you pass in a %Cat{}, "input" will be bound to the atom Cat
end

Nitpick: since this has a complex expression on the left-hand side, “initialize” is not quite the right verb - as the error message says, this is a failure to match. This would be fine:

%{__struct__: Cat} = %Cat{type: "Maine Coon"}

since the match requires all the keys in the map on the left to be present in the map on the right.

5 Likes
7

Sorry if I wasn’t being clear (it seems like it’s been a thing yesterday),

It’s present

You’re right, the __struct__ exists in both places.

iex> %Cat{} = Map.delete(%Cat{}, :type) 
%{__struct__: Cat, weight: nil}
iex> %Cat{} = %Cat{}
%Cat{type: nil, weight: nil}

But that’s again, kinda getting at the base of my problem. Given that both have __struct__ as part of what it is, and the fact that you can only see it in the output that it’s incorrect.

The struct, obviously, is syntactical sugar over map, but, is there just no comparison/matching that exists that would tell you that the struct that’s been altered by deleting a key does not actually match the same struct?

8

You could do the same thing the Inspect protocol does: compare the keys in the input with the keys from the module’s __struct__() function (which generates the same thing as writing a struct literal with no keys):

IMO this is a “why is it so hard to put my finger in the live electrical outlet” problem - it’s hard to deal with broken structs because you really shouldn’t be making them…

1 Like
9

And in my experience they’re pretty hard to make in real world code by accident. I’ve been coding Elixir full time since structs were added to the language and I can’t think of any time this has been an issue for me.

2 Likes
10

I mean, yeah, obviously, don’t break structs, but are there any facilities for actually determining that a struct is broken once it is?

11

Just for fun you could write a function based on the Inspect.Protocol referenced by @al2o3cr

  def struct_or_bluff(%{__struct__: module} = accused) do
    if Map.keys(module.__struct__()) == Map.keys(accused) do
      :struct
    else
      :bluff
    end
  end

  def struct_or_bluff(_), do: :not_even_pretending

(but don’t)

Incidentally

%{%Cat{} | variance: "tabby"}

doesn’t fail because of much to do with it being a Struct or not. It fails because the key doesn’t exist.

%{%{} | variance: "tabby"}

also fails

Map.put(%Cat{}, :variance, "tabby")

succeeds and also produces one of those “invalid structs” (that you will never really have to worry about as @benwilson512 mentioned).

2 Likes