I assumed that in order not to break existing code, case would have to be the non-exhaustive version, therefore raising at runtime, while case! would be exhaustive. But it would certainly make sense to do it the other way around if possible.
Sorc96
0
kwando
This is very superficial, but I think case! is kinda ugly 
case! value do
{:ok, value} ->
do_something(value)
end
also
case! value do, case !value do, case! !value do, case !!value do, case! !value do, , case! !!value do
would all be different (most of them would probably be better as if expressions, but still).
5
wanton7
Isn’t plan to just have compiler warnings? So I’m not sure that would count as breaking existing code.
Edit: Example when C# changed string to be non nullable it was just a compiler warning. I think it still might be but I haven’t used C# for a while. You can change that warning to error if you want. I would expect Elixir to go that same route.
1
radarjones
ityonemo
Yep this is exactly the problem. We need a “principled type system” that reflects specific needs of the system, where the sets in the type system mean something.
1
zachallaun
While reading the paper, I noticed reference to two as-yet unpublished companion papers:
[8] Giuseppe Castagna. Typing records, maps, and structs. Unpublished manuscript
(conditionally accepted to ICFP 2023, the 28th ACM SIGPLAN International
Conference on Functional Programming), April 2023.[9] Giuseppe Castagna and Guillaume Duboc. A gradual type system for core Elixir.
Unpublished manuscript, April 2023.
Any word on when drafts of these may be available?
0
josevalim
Creator of Elixir
The first one depends on the conf. The second is not yet submitted afaik. But those will be fairly more technical (I am not an author).
2
alessandro
re: exhaustiveness, maybe something like Sorbet’s T.absurd might come in handy?
As someone who worked on a very large Ruby and JS codebases with optional types added on top, I have a lot of Opinions ™ on the subject, but having compile time checks beats not having them for sure, so am very excited for this development in Elixir!
0
cjbottaro
My thoughts exactly.
Oh, I see.
Hmm, I would be down for a nicer syntax!
Oh, I hate it.
What a roller coaster! I kid about hating it, it’s just not what I’m used to (typespecs).
For the massively uninitiated like myself, why doesn’t Elixir just copy TypeScript? I’ve never actually used TypeScript, but friends and colleagues keep showing me what it’s capable of and it’s quite impressive. From what I understand, it’s opt out, and Elixir’s system has to be opt in? Is TypeScript “set theoretic”? If not, what’s an example of something set theoretic can do that TypeScript can’t and what are the benefits?
I am super excited for this btw. I was porting some code to Go the other day and came to the realization that I can work much faster in a statically typed language despite the extra verbosity, and in this case, many more lines of code.. It has to do with being able to remove context from my head… kinda hard to explain, but it’s like you can let go of a lot of things mentally. All that benefit goes out the window as soon as I have to deal with JSON that has non-homogenous arrays though… 
1
sodapopcan
See quote from the paper in another thread. TL;DR, requirements make that sort of style a no-go. Requirements aside, this comment along with the linked library, is also insightful.
3