Hello guys
Hello guys,
I can see Nullable types support in Delphi but what about Non-Nullable types support in Delphi? It would help us to avoid dancing with Acess Vioalations, mostly of these run-time errors could get translated to compile-time errors.
https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/
https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
:D
I can see Nullable types support in Delphi but what about Non-Nullable types support in Delphi? It would help us to avoid dancing with Acess Vioalations, mostly of these run-time errors could get translated to compile-time errors.
https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/
https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
:D
Cute - I was under the impression that non-nullable types have existed in Delphi right from the beginning...
ReplyDeleteI don`t think so :( Non-Nullable types in Delphi would help us to avoid dancing with Access Violations :(
ReplyDeleteHorácio Filho I have no idea what you mean by "non-nullable", but from your comment it sounds like C++ references.
ReplyDeleteI miss references very, very much.
I was very impressed when I saw the approach of nullability by Apple Swift language which should be you referred to. Neither reference types (such as class) nor value types can be null unless you explicitly mark them as optional. e.g. 'obj: TObject' is ensured to be not nillable by the compiler. you must use 'obj: TObject?' to indicate that 'obj' can be nil. That means a lot.
ReplyDeleteHorácio Filho non-nullable types in Typescript are like classic Delphi types, they're only a "novelty" in the JS world because everything in nullable by default (side note: types in SmartPascal are non-nullable like in Delphi)
ReplyDeleteThe C# link you posted is a bit different, and looks to me more like someone had a nullable types overdose. The proposed syntax is cute though... in a DailyWTF way ;)
While there are valid use cases, I suspect the author is more after new carpets to hide his messes under, or new ways to pass the undetermined-states-hot-potatoe down the line.
The whole point of exceptions is to break away form old-fashioned C-style patterns, when exceptions were fatal, and everything would fail silently and assume more or less correct default values (usually less).
In JS there is a distinction between undefined and Null, but for object languages where there is only Null (or nil), you have an ambiguity because a null can indicates something that is undetermined, and undetermined does not mean the default value... so you have a slippery slope which leads to carpets, potatoes and old C-style patterns.
Asbjørn Heid I mean "non-nullable" by types whose instance cannot hold nil. If it is not initialized before it is deferenced, the compiler should generate a error message.
ReplyDeleteHorácio Filho That's why I liked C++ references.
ReplyDeleteThough you could get a lot of the same by simply configuring the "W1036 Variable might not have been initialized" warning to be an error (in project options), no?
Horácio Filho Oh I forgot that the compiler doesn't warn on managed types, my bad.
ReplyDeleteAsbjørn Heid Because of the way Delphi/Pascal is designed to have variables defined beforehand it would not work the way that C++ references work (they need to be initialized).
ReplyDeleteSo in order to implement them properly in Delphi the compiler would need to treat missing assignment or assignment of nil as an error.
Anyway the concept of non nullable types is only a subset of things like contracts (not the C++17 contracts though because afaik those are runtime checks). So I rather would like to see something like compile time checked contracts in Delphi which would greatly improve code and avoid many bugs. However this requires a pretty heavy static code analysis done by the compiler to ensure that any possible code path meets the required contract.
I cannot find the video right now but there is one about Microsoft contracts where the presenter mentions that they could delete the majority of their unit tests because after using contracts they would not even compile anymore because the compiler prevented passing wrong input.