After reading some more replies here I’m going to go sit on the fence.
sodapopcan
zachdaniel
Creator of Ash
Actually I don’t think this fully holds.
%{} create new map
%{var | key: 10} → create a new map, with all the same keys but key set to 10
%Mod{} → create new Mod
So then we’d get to: %Mod{var | key: 10}
which by the composition rules you’re describing should make a new Mod with all the keys in var except key set to 10.
i.e:
%Mod{} → %{__struct__: Mod}
%Mod{var | key: 10} → %{var | __struct__: Mod, key: 10}
In typing this out, I guess its debatable if
%{var | __struct__: Mod, key: 10}
would be the right interpretation, or
%{%{__struct__: Mod} | , key: 10} in which case you’d be right?
Not sure 
2
christhekeele
In my mind it’s conceptually closer to the latter, but YMMV.
Less important, and I’m not sure I’m reading the actual implementation correctly, but if so it appears that
- struct update syntax is special-cased (rather than emergent)
- to model a map with the correct
:__struct__key, - then apply the updates.
So closer to the latter than the former, but implemented specifically rather than emergent from expansion order of the two constructs.
1
zachdaniel
Creator of Ash
I think your point is salient FWIW. The fact that you can’t use them together might trip people up, but I do think there is still a subtle difference whereby the composition doesn’t necessarily do what it looks like it would do when combining the two. Perhaps a matter of perspective.
[a | b] is an example where the same symbol has totally different properties based on its surrounding context, for however much that adds to the conversation 
I do think that the strategy of just requiring that the value match the type if you use struct update syntax is a really elegant solution to the stated type system related issues, to the point where the motivation to remove the syntax seems to have been handled. If it’s coming back down to preference given that the technical issue is solved, then there is no great reason to debate the issue, and IMO no significant reason to deprecate it (and I voted on the poll as such).
3
Eiji
So in other words some dependencies or tools like LSP have to be updated to support new version of the language which is completely expected I guess … This is why they announce updates sooner and give release candidates, so the community would know more about it and decide if it’s the right time to make an update. 
In my case I’m already working on new release candidates mainly because what I commented above and because of optimisations. I see things are really going in a good direction and I’m very motivated to not stop them from making good things. 
1
sbuttgereit
I find myself in the camp that likes the explicitness of the struct update syntax. When I see such an expression, I just don’t have a question about what the thing is and I’m clear in the communication to other readers, too. By using the map update syntax, we weaken that more explicit expression. That’s my simplistic take on the matter.
This isn’t to say that the pattern matching warning is unwelcome or that I want to avoid the pattern match because we have the struct update syntax… just that if I have a struct I don’t want to lose the discipline of treating it as such everywhere I might reference it.
And no, if it is deprecated I won’t lose too much sleep.
One final note on deprecation. There are a number of libraries out there, some of them that get some use, but perhaps less maintenance. While in some sense they may be “done” and not require a lot of attention, deprecations can cause a sudden requirement for attention which might not be readily available. I still use libraries which cause warnings about charlists and not using the sigil, though for all intents and purposes they continue to work fine, if noisily during compile. But these libraries aren’t looking like they’ll be updated anytime soon ether. That’s the only concern that I really have given some of the thinness of support for some these things.
3
Eiji
defmodule MyStruct do
@moduledoc "module documentation"
defstruct [:my_field]
@typedoc "field documentation"
@type my_field :: …
@typedoc "struct documentation"
@type t :: %__MODULE__{
my_field: my_field()
}
# could be also done with a single and simple reduce similarly to for statement below
@type field :: {:my_field, my_field()} | …
@type fields :: [field()]
@doc "put/2 documentation"
@spec put(t(), fields()) :: t()
def put(struct, fields), do: struct(struct, fields)
@doc "put/3 documentation"
def put(struct, field_name, field_value)
for field_name <- [:my_field] do
var = Macro.var(field_name, __MODULE__)
@spec put(t(), unquote(field_name), unquote(var)) :: t()
def put(struct, unquote(field_name), unquote(var)) do
Map.put(struct, unquote(field_name), unquote(var))
end
end
end
With this code:
- We can easily create a generic macro if we want to do same thing for many modules.
- We have ful LSP support, documentation and specification
- We no longer need struct update syntax
# old
%User{user | address: "Earth"}
# new
User.put(user, :address, "Earth")
# or
User.put(user, address: "Earth")
There should be no problem with readability, code completion and so on … We already have a good patterns that we can follow, so there is really no need for a struct update syntax.
1
mudasobwa
Creator of Cure
Just my ¢2.
I don’t have anything against %User{user | age: user.age + 1} syntax, but it feels counter-idiomatic to me beyond two main usecases: ① User is somewhat “more” than a structure and updates are nevertheless should pass through kinda validation (via Changesets in Ecto, or via Access in Estructura,) and ② state management in GenServer callbacks. I personally very rare if never met floating-by structs being just updated in the wild.
Assuming that ① is covered by the respective helpers (direct update with %_{_ | kv} is nevertheless should be avoided at any cost,) we have ② left. Yesterday I managed to clean up my libraries from the not-yet-but-to-be-deprecated syntax and I can tell, one would not miss these endless %__MODULE__{state | key: :value} in {:reply, …} and {:noreply, …} clauses.
Theoretically I can relate to the opinion %User{… | kv} is more suggestive, but in real code in my experience it is not. 99% of cases are covered by ① and ② above, and in ① there is no such thing as a direct struct update, while in ② it’d be rather %__MODULE__{… | kv} than %State{… | kv}.
The 1% left should be IMHO covered by introducing helpers within the module declaring a struct, as José mentioned above.
That all being said, I am voting for less noise, specifically taking into account that inability to sweep the unclearance of the code under the rug of final “boom! it’s still a user struct!” would eventually but inevitably force us devs to write cleaner code avoiding updates of who-the-hell-knows-what-this-struct-is in 20 lines under it’s definition 
5
adamu
If as a result of the change, someone replaces this:
def update(foo) do
%Foo{foo | bar: "baz"}
end
with
def update(foo) do
%{foo | bar: "baz"}
end
is there a way to realise that foo is always a Foo and warn then that writing
def update(%Foo{} = foo) do
%{foo | bar: "baz"}
end
would be better? I think this is the main thing that would be lost by deprecating the syntax, if the result is code that might cause bugs by performing operations on any map/struct that happens to have the right keys, when the intention was only ever to operate on a specific struct.
5