In my opinion focusing this on records is a red herring. In neither elixir nor erlang can you prevent non-native “datatypes” from being created without custom validation. You can always manually construct the lower level data directly used to represent higher level data. This applies to both records (custom user land types common in erlang) as well as structs (custom user land types common in elixir), but likely also any other option you could come up with using the native types we have. If there is a way I’d expect it to come with other downsides, like e.g. considerable runtime overhead.

Comparing this to approaches in statically typed languages (as you’ve been expressing in prev. posts) is imo not a great idea given their type system and specifically it being static is what makes many of those approaches possible/viable in the first place.

To be a bit more concrete in regards to records: Records are just a convention around tuples (first elem is an atom denoting the type) just like structs are a convention around maps (__struct__ key + small api defined by the struct modules). You can construct a user record manually by doing record = {:user, name} similarly to constructing a struct manually. Neither of both approaches is meant to prevent people from doing that (given it’s effectivly impossible to enforce).

So what are the alternatives? None if it’s about the compiler / code level enforced validation. But you can still have project level conventions of having your team call MyType.new(…) as the only valid way of constructing a type picking up violations e.g. in code reviews.

You can take a look at MapSet. It deals with all of the questions you had. It’s not a native type, but is meant to maintain “set” properties. It does so by marking the internals as @opaque t::… to tell dialyzer nobody but the module itself may update values returned by the API and then basically expecting people to only supply valid mapsets for all the API receiving existing sets.

Edit: Also dialyzer will yell at you trying to modify internals of an opaque type return value. Doesn’t prevent the “created manually” case though afaik.