Correct, but it requires actual mutable state, has worse performance, and has a less friendly user experience as the compiler cannot tell you when you are accessing something that could have been “dealocated”. So the question is: solving this problem in a faster, immutable, and with better dx worth the syntax additions?
Yes. They can be used anywhere a variable would be used.
The is no mutability in the proposal. It is “just” enabling rebinding within the scope the variable is declared and all inner scopes.
We can already rebind variables within a scope, we can’t rebind them from inner scopes. The proposal is essentially relaxing this restriction and using a designated prefix to distinguish them and to avoid some unintended shadowing use cases.
I say avoid because if these do catch on then there still will be accidental shadowing. You may intend to introduce a new @@foo one scope down and you end up shadowing a previous but different @@foo in the same function.
The most insideous case would be a module level @@foo in another ModuleB that gets imported into the current ModuleA. Does that ModuleB @@foo get imported too?
If yes, and I have also have a ModuleA level @@foo, which @@foo would be used? Perhaps a compiler error leading to fragile code evolution?
What if I am implementing a callback for a behaviour?
Does the @@foo in my function use ModuleB’s @@foo if I haven’t declared a @@foo in ModuleA?
Or if we do declare a ModuleA scope @@foo do we have two instances of @@foo, where functions in ModuleA use that modules @@foo and the functions in ModuleB use the @@foo in ModuleB and now we have inconsistency between the @@foo used in functions we inherit from ModuleB but don’t override and those functions we implement?
This kind of cross module gymnastics with module scoped @@foo almost reminds me of multiple inheritance hell in C++
You wouldn’t be able to import or access a variable or local accumulator from ModuleB, unless it is via a macro. The problems you are describing would not really happen. And in the macro case, we already have variable hygiene.
Just ask yourself: can I access a variable defined in moduleB from moduleA? If the answer is no, then you cannot access a local accumulator either.
I’m aware 
That’s why I prefixed it with “(not really)”.
I’m not sure I follow what you mean by “importing @@foo”. If you mean by using the import feature, I don’t think it would be possible (just like we can’t import regular variables defined at the module level).
If you’re talking about meta-programming, macro hygiene should have us covered. Take the following code:
defmodule ModA do
defmacro __using__(_) do
quote do
my_var = 1
end
end
end
defmodule ModB do
use ModA
IO.inspect(my_var)
end
This gives a compilation error since from ModB perspective, my_var doesn’t exist. My understanding is that the same would be true with the @@ variables.
Similarly, you can’t mutate a module-level variable from a function not because they are in different scopes, but because they are in completely different execution environments. For instance:
defmodule MyMod do
my_var = 1
def my_func do
my_var
end
end
This gives a compile error as well. You’d need to interpolate the variable using unquote:
defmodule MyMod do
my_var = 1
def my_func do
unquote(my_var)
end
end
MyMod.my_func() # => 1
Again I believe this would be the same behavior with the @@ variables.
Thanks for that.
However we would have functions in ModuleB using that modules @@foo and any functions we override would not have access unless provided through some ModuleB function just like a normal module attribute.
In respect of a module level @@foo and regular module attribute @foo, what is the material difference? Is it just the assignment syntax?
Given you can’t rebind to a module level @@foo at runtime I assume this would generate a compiler error or would you allow a function or inner scope to shadow a module variable?
If I understood correctly, @@foo would behave more like a normal variable foo than like a module attribute @foo:
defmodule MyMod do
@foo :a
foo = :b
@@foo = :c
def my_func do
# you need to unquote `foo` and `@@foo` to access their value here
{@foo, unquote(foo), unquote(@@foo)}
end
end
I think the value of something like @@foo at the module level would be fairly limited, as we rarely use nested scopes in the module level (like if/for/case), unless you’re doing metaprogramming, in which case it could be useful:
defmodule MyMod do
@@counter = 0
for name <- [:foo, :bar, :baz] do
@@counter = @@counter + 1
def unquote(name)(), do: unquote(@@counter)
end
end
MyMod.foo() # => 1
MyMod.bar() # => 2
MyMod.baz() # => 3
Although the above is already possible today by redefining module attributes:
defmodule MyMod do
@counter 0
for name <- [:foo, :bar, :baz] do
@counter @counter + 1
def unquote(name)(), do: @counter
end
end
And what about this?
defmodule MyMod do
@@counter = 0
def alpha(), do: @@counter
for name <- [:foo, :bar, :baz] do
@@counter = @@counter + 1
def unquote(name)(), do: unquote(@@counter)
end
def omega(), do: @@counter
end
MyMod.alpha() # => 0 ??
MyMod.foo() # => 1
MyMod.bar() # => 2
MyMod.baz() # => 3
MyMod.omega() # => 3 ??
Or does it not compile?
It would be a compile error, yeah, you’d have to do something like:
defmodule MyMod do
@@counter = 0
def alpha(), do: unquote(@@counter)
for name <- [:foo, :bar, :baz] do
@@counter = @@counter + 1
def unquote(name)(), do: unquote(@@counter)
end
def omega(), do: unquote(@@counter)
end
In which case they would take “snapshots” of the current value of @@counter (since unquote is evaluated at the module-level in these cases). So I believe that with the proposal it would work something like:
MyMod.alpha() # => 0
MyMod.foo() # => 1
MyMod.bar() # => 2
MyMod.baz() # => 3
MyMod.omega() # => 3
Which again is already possible today with plain module attributes:
defmodule MyMod do
@counter 0
def alpha(), do: @counter
for name <- [:foo, :bar, :baz] do
@counter @counter + 1
def unquote(name)(), do: @counter
end
def omega(), do: @counter
end
So I don’t think this proposal would have an impact on how module-level values would leak to function-level scopes, as essentially all that would be made possible at the module-level is already possible with module attributes today.
I would go as far to say they are pointless or even harmful at module scope given they only serve to create shadowing issues with function scope usage.
Existing module attributes do a sufficient job already and we don’t need module scope @@foo clashing with function scope, nor do we need to add extra typing to unquote/crystallise them when we have module level @foo already.
I would therefore suggest the proposal be paired back so that @@ be considered only within runtime scopes and let module attributes handle the compile time usage.
Functions always start a new scope, and that would be the case here, so no shadowing because no module variable leaks in. The model is simpler than you are thinking. 
That’s typically a bad idea because Elixir doesn’t really make a distinction between runtime scope and compile time scopes. Runtime and compile-time is the same. That’s why you can use if or any other function/macro inside module bodies and you can also define modules inside functions. Even defmodule itself is just a macro and there is not much special about it.