Another solution is not to use

when

and '`=` together

I tend to favour single-expression functions where possible, and "when" forms fit very nicely with recursion, so I don't find the formatting especially bothersome; maybe moving the "where" onto the line after the signature would help readability a bit.

Good idea

@domfox if you reformat the article, could you please ping me?

Btw,

for(r in -40.0..40.0)

would work as expected

mandelbrot_function_formatted_for_better_readability.kt

There isn't a "leverage" for something that isn't there.

Sure there is. You can leverage the fact that the runtime won't type check something.

I suspect also that .net requires you to supply a lot of information to materialize type information, and most of that information is simply not available coming from the JVM bytecode

🤷 I don't follow your line of reasoning as it pertains to a type system.

As an example, if I know the runtime isn't going to type check, I can cast to whatever I want.

sure, it leverages the erased generics to produce a more powerful type system

But then you're stepping outside the type system.

which you cannot implement in a reified system

Because of type erasure, all generic types in the JVM is an object so I can tell the JVM, "this is a Foo" when it isn't.

Sort of. ClassCastException will still pop up.

Really?

But casts are beside the point.

That would imply that the real type isn't actually erased?

yeah, but you can design a more powerful type system that can prevent it from happening at compile time

No, simply that you can cast List<Foo> to List<Bar> -- not Foo to Bar.

Java will refuse to compile certain casts. At the JVM level, you can do a lot more things.

It's still unlikely to be useful, as it would then fail at runtime when you have Bar bar = fooList.get(0)

Sure, was just a simple example of something you can do in a type erasure world.

But type systems are about what you can express without casts. It's pretty boring to say what you can do with casts.

I can open up /proc/<my proc>/memory as a ByteBuffer and do whatever I want.

I would say the strongest argument for type erasure is that "it only ever matters if you are doing reflection, and you should never use reflection".

Though, even that is pretty weak since reflection is an incredibly powerful tool (if wielded wisely).

@zoltu: That was my strongest point in the blog, yes

Reification implies second guessing the compiler.