On Wednesday, 21 November 2018 at 23:27:25 UTC, Alex wrote:
Nice! Didn't know that... But the language is a foreign one for
me.
Nevertheless, from what I saw:
Shouldn't it be
var x: C?
as an optional kind, because otherwise, I can't assign a nil to
the instance, which I can do to a class instance in D...
and if it is, it works in the same manner as C#, (tried this
out! :) )
This is true. But then the difference is that you can't* call a
method on an optional variable without first unwrapping it (which
is enforced at compile time as well).
* You can force unwrap it and then you'd get a segfault if it
there was nothing inside the optional. But most times if you see
someone force unwrapping an optional it's a code smell in swift.
Comparing non-optional types from swift with classes in D is...
yeah... hmm... evil ;)
Hehe, maybe in a way. Was just trying to show that compilers can
fix the null reference "problem" at compile time. And that flow
analysis can detect initialization.
And if you assume a kind which cannot be nil, then you are
again with structs here...
But I wondered about something different:
Even if the compiler would check the existence of an
assignment, the runtime information cannot be deduced, if I
understand this correctly. And if so, it cannot be checked at
compile time, if something is or is not null. Right?
Aye. But depending on how a language is designed this problem -
if you think it is one - can be dealt with. It's why swift has
optionals built in to the language.
