Well that’s the problem, they don’t work with the Elixir AST; they work with TreeSitter tree structures. Any DSLs – not only in Elixir and not only Ash – trip those tools up.
This is definitely not a criticism on Ash. I am explaining limitations in tooling that I found.
I don’t understand how a DSL that is valid elixir syntax could have the property you are describing. The tree sitter grammar covers Elixir syntax. If it didn’t work, syntax highlight DSLs would also break (which it doesn’t). Only exception is sigils (which Ash doesn’t use).
I meant it in the sense that those tools don’t find certain results in the code in response to queries (that’s what they do, they allow you to search in code without regexes and thus be more “aware”; and that’s where TreeSitter comes in). I’ve isolated those failures to DSLs but it did happen with a few other idioms as well. I’ve not kept examples so can’t provide them. Sorry.
I feel like the old struct update syntax encourages fuzzy thinking, deprecation is the right move.
If you write:
new_user = %User{user | email: new_email}
You are saying two things
user is of type UserThat syntax serves mixes two unrelated purposes together: assertions and updates. So this leads to bad habits.
I reviewed my own code to see for myself. Many of my uses of the %User{user | email: new_email} syntax were lazy thinking. By chance, I was updating a variable and I thought “oh why not let me make sure to assert the struct type”. If I had thought of assertions on their own, in 90% of the cases, I would have asserted much sooner than the update to catch failed assertions earlier.
And one more point: I think readability can be solved better at the editor level rather than the language level.
For example Zig chooses to show inferred types inline:
I did not type any of those gray types. The type inference is telling me what they are!
I personally find the above to be a bit noisy, but my point is, this does not need to be solved at the language level.
Solving this at editor layer has a few advantages:
I’m aware of how they work but I’d suggest that it’s unlikely to be anything beyond user error 
DSLs are just elixir expressions, i.e
schema "schema" do
field :foo, :string
end
Is, to tree sitter, just two function calls.
schema("schema", do: field(:foo, :string))
No idea what happened a year or so ago then.
But you got me curious. I’ll check again in an Ash project. Bookmarking this.
Sorry for necrobumping this thread. I only just saw this topic and wanted to post my 2 cents since this is planned to be revisited for v1.20. 
It looks like a lot of the discussion around the struct update syntax is related to type inference/assertions/safety and how this affects the maintainability of a project. I regularly work in Typescript professionally, and I’ve also done a lot with static typing in Python and some C++, so I would like to add some perspective from other languages to the discussion in case its helpful since they can provide examples of non-obvious problems.
tl;dr
I think the struct update syntax as a type assertion has value for self-documenting code but would actually lead to extra maintenance burden over time. Offloading too much work to the type checker can have a significant impact on compile times, so it’s often not worth it when alternative patterns exist. If the removal of the direct struct update syntax can simplify the compiler architecture, this may make it easier for the compiler team to make more significant improvements in the future, but I’m not a compiler engineer so that’s just conjecture on my part.
About type assertions
My experience with static typing (particularly structural typing) is that developers tend to overuse declarative typing inline instead of defining proper interfaces around their functions and classes.
I fell in love with Elixir the first time I used it because it has incredibly expressive function declaration syntax. Being able to pattern match in the signature of a function and set an @spec that says the return value is a particular struct or has a particular shape like {:ok, non_neg_integer()} | {:error, String.t()} is sufficient for ensuring type safety throughout a program and also for human readers to know what to expect. If I’m calling a function, I only need to know what arguments it takes and what it is supposed to return. If I get something different out of it, that’s a bug in that function, and I can go and fix it or file a ticket with the team that maintains it.
If the compiler can determine that the return type is incorrect based on the function head via pattern matching, I can focus on defining my interfaces through the function signature and I don’t have to add a bunch of defensive type checking code in the body. And none of the consumers of my code need to care about what I’m doing inside that function either. This reduces the surface area of code that needs to be updated during a refactor as well, so the code is more amenable to change.
Complex or dynamic code that doesn’t use pattern matching or guards in the signature and can’t be verified by the type checker should be covered by a parametrized unit test. No amount of static analysis will make up for a missing unit or integration test for dynamic code.
About maintenance
The self-documenting nature of the struct update syntax inside a function body is definitely a real benefit, but it can also become a maintenance burden when updating data structures due to a refactor or after iterating on a core module and improving its design. Particularly if used in a conditional branch inside dynamic code.
Something like this (not typesafe, just an example of the refactor cost):
def conditional_func(x) do
if (some_condition(x)) do
%MyStruct{x | key: val}
else
:something_else
end
end
If instead of the inline assertion, we used pattern matching in the function head for an overloaded function call like this:
def conditional_func(x = %MyStruct{}) when some_condition(x), do: %{x | key: val}
def conditional_func(_), do: :something_else
That refactor would be a lot less painful since all of the updates related to that data structure would be contained in a single implementation of the conditional_func instead of spread throughout different conditional branches in function bodies. If the compiler can guarantee the same level of type safety in both versions, I see no reason to have the inline assertion via struct update syntax.
Another problem with moving more work into the type checker is that type checking is not free. Developers such as myself tend to treat the type checker and the compiler as a magic black box that has no cost since it’s not part of our application, but this is untrue. Compile/transpile/build times are a significant factor for DX. This is painfully obvious in large Typescript projects that do a lot of type inference. Build times are often abysmal past about 20k LoC, and they can actually impact a team’s ability to meet deadlines. This is particularly painful for R&D programmers (which is mostly what I do) since we tend to do more exploratory coding and refactoring than is typical in regular application development. I love Elixir, and I really don’t want it to become anything like Typescript.
I’m not a compiler engineer, so I don’t know how accurate this all is, but I would think that removing a special case from the compiler code would open up a lot of possibilities for new optimizations. In application development, special cases always make iterating and improving difficult because we can’t just redesign a data structure or implement a new pattern. We have to add that one extra conditional to every new feature we implement to account for that legacy code path that no one has time to rewrite. And every time we do that we increase the cost of finally refactoring/rewriting since we now have one more piece of code that has to be updated during that work. I would think that even if the first-hand effect of removing the struct update syntax makes no real difference, the reduced cost of implementing new features and optimizations in the compiler will have a compounding effect on quality and speed over time.
Sorry, this got super long, but it’s a very interesting topic, and I hope this perspective is helpful in some way.
FYI, I love your take. One of my top 3 complaints towards Rust are compile times. It can and does rid you of an entire class of bugs just by the mere virtue of the program compiling but I sometimes want to yell at my computer when a recompile takes 15 seconds.
I agree that correctness and DX must be balanced. Full support.
That being said, if I was forced to pick one of the two with a gun to my head, I’d still choose correctness.
Yeah, most of my fear of compile times comes from C++. I actually had to buy a better laptop a while back because it took too long to compile Godot from source when I was trying to do small bug fixes. 
I agree that if I had to choose I would prioritize tooling to ensure correctness at compile time, but in this case, I’m arguing in favor of removing the struct update syntax because IIUC the compiler can still provide the same (or even better) guarantees with pattern matching in the function head or variable declaration instead of the inline type assertion, so in this case, the tradeoff is readability and not correctness.
Readability is often subjective, but poor readability can also can lead to incorrectness, so it’s an important factor to consider as well.
But I really do believe that Elixir’s pattern matching is powerful enough that this won’t become a problem in practice. It will definitely take some getting used to though.
If it turns out that we lose something significant on the correctness front by removing this inline assertion, than my vote would probably change.
I think it’s similar to how it took me a few weeks to stop looking for the word “return” in every function and just start reading them as self-contained blocks of expressions when I first started learning Elixir.
This is a valid point, however i doubt this brings that much burden that it’s gonna slow anything to keep the syntax.
Especially so that it’s an opt-in feature. If, in my code, I’m using %User{user | email: email}, i’m okay to accept there’s gonna be a bit more compiler involved. If compile time becomes so much of a problem that I wanna make any improvement possible, I can always come back to it and convert those to %{user | email: email} and save these extra steps.
I see this a little bit as @doc, @spec or behaviours. You don’t need to use them, but you can if you want to improve documentation of your code and the readability at the cost of a bit more compile work (maybe not in prod, though).
By the way, we upgrade our app to 1.19.2 this week and it helped us uncover a couple of places where we were missing pattern match beforehand (where we only had struct update), the warning is a really nice improvement, we would have miss those bits if we weren’t using struct update syntax and only map update syntax. I love it how it is right now personally.