It was mentioned many times that Embt will introduce nullable types into Delphi. I was wondering what it will look like. However, is that really on top of our wishlist? I don't think so. (especially without null-propagation or swift-like nillable) we have Nullable in Spring4D.
It was mentioned many times that Embt will introduce nullable types into Delphi. I was wondering what it will look like. However, is that really on top of our wishlist? I don't think so. (especially without null-propagation or swift-like nillable) we have Nullable in Spring4D.
Instead, I would suggest Embt consider introducing standard function *NameOf* and *interface helper*. These two features will fundamentally changes a lot of things with "minimum" cost (In my mind of course).
Instead, I would suggest Embt consider introducing standard function *NameOf* and *interface helper*. These two features will fundamentally changes a lot of things with "minimum" cost (In my mind of course).
Attila Kovacs Yeah I bet every 3rd party will turn every Integer result into nullable Integer because ... ?
ReplyDeletePoor C# developers that have to deal with all these nullables every time - I guess they cannot even sleep because they have nightmares from all their multiplications suddenly returning nullables...
And meanwhile a Delphi developer laughs at them and keeps using Variants for database things because that is so much more safe... right? Spoiler alert: it's not!
Stefan Glienke: you're taking about a specific implementation (probably to duplicate what C# does). Nowadays I spend most of my time programming in languages where every variable is implicitly nullable (JavaScript, php, python, SQL).
ReplyDeleteThe much stricter type enforcement is a relief when I get to do some Delphi programming again.
I think I could live with explicitly defined nullable types, as long as other variables are not automatically "promoted" to it. E.g. a nullable int with a normal int should not compile. Otherwise, one nullable could pollute an entire codebase.