tadiou
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.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Nicd
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.deletefunction 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).axelson
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:tadiou
Okay this makes a bit more sense here! But then…
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? LikeAnd just for thoroughness, we’d expect that
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?
Sebb
Just don’t break the structs, Elixir is a dynamic language and requires some countenance.
al2o3cr
It’s present, that’s how
inspectknows to format it as%Cat{...}instead of%{...}.You can even write code that matches on
__struct__: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:
since the match requires all the keys in the map on the left to be present in the map on the right.
tadiou
Sorry if I wasn’t being clear (it seems like it’s been a thing yesterday),
You’re right, the
__struct__exists in both places.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?
al2o3cr
You could do the same thing the
Inspectprotocol 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):https://github.com/elixir-lang/elixir/blob/898d80e46c78b006cc1b951208e53fe7c67c02a1/lib/elixir/lib/inspect.ex#L440-L454
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…
benwilson512
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.
tadiou
I mean, yeah, obviously, don’t break structs, but are there any facilities for actually determining that a struct is broken once it is?
paulanthonywilson
Just for fun you could write a function based on the
Inspect.Protocolreferenced by @al2o3cr(but don’t)
Incidentally
doesn’t fail because of much to do with it being a Struct or not. It fails because the key doesn’t exist.
also fails
succeeds and also produces one of those “invalid structs” (that you will never really have to worry about as @benwilson512 mentioned).