The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My work

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming

    20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now

    20140424-Windows-7-free-disk-space

    More Photos
  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,757 other followers

Real nullable types will probably never make it to the language, but wel can still dream

Posted by jpluimers on 2016/10/06

Allen Bauer (ex Delphi R&D team) wrote the brilliant piece about a year and a half ago. We can still dream, right?

Allen Bauer, May 25, 2015

Current working theory of Nullable<T>.

Nullable<T> = record

property Value: T read FValue; default;

end;

Using the default directive to “hoist” the operators of “T“. Currently the default directive only works for array properties by “hoisting” the ‘[]‘ operator. Marking a non-array property with default will make the containing type behave as that type.

This, coupled with some intrinsic compiler knowledge of the Nullable<T> type will make Nullable<T> work without any addition of keywords or other standard functions or procedures.

Using the “default” directive on a non-array property will work for any type, except for having the null-propagation semantics.

When considering language features, I try and not only make it work for the intended purpose, but also broaden reach of any supporting feature. In the above scenario, even user-defined operators on “T” will be properly hoisted and used.

This was part of a very interesting G+discussion at Delphi’s New Feature Desired: Nullable Types and Null Propagation….

It covered topics like these:

–jeroen

5 Responses to “Real nullable types will probably never make it to the language, but wel can still dream”

  1. kmorwath said

    Do you know Hejlsberg instead decided to remove nullable types by default from Typescript v. 2?

    https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

    IMHO nullable types brings more disadvantages than advantages.

    • jpluimers said

      That’s because there you can have union types as described in your link.

      • kmorwath said

        Yes, but the post also states that nullable types are the sources of many issues in JavaScript, and that’s why they has been removed, with the option if you really need them for a good reason, to ask for them explicitly. I would no problem in Delphi if nullable types were optional. If default types are nullable, it will just make things uselessly more dangerous. Delphi fans may not have noticed yet, but there is a resurgence of strongly typed languages with a lot of compile time checks to deliver more robust code. But it looks Delphi is still lagging behind in its design goals, and still aiming at JavaScript, a language barely acceptable on web pages, for lack of better alternatives. TypeScript itself is an attempt to plug the dreadful JavaScript holes – really, is hard to understand why Delphi should throw away many of the features of Pascal, exactly those features languages are rediscovering due to the many issues caused by “easy to use” languages, in exchange for what? A little less time spent in writing code, and much more in ensuring it works as expected and doesn’t have nasty hidden bugs?

        • jpluimers said

          I always assumed that – if Delphi would ever get nullable support in the language at all – nullable would be an optional thing just like in C# or with the Boost library in C++.

          I didn’t know JavaScript had nullable as a default for all types, so now I know what you meant with your original point.

          Thanks for clearing that up and teaching me a new thing.

          –jeroen

  2. yep, “default” is a dream with multiple advantadges (if it can work at low-level everywhere, including in classes). For example you could now make TButton.Caption a class instead of a string property (with a Text:string default property), all code using Button1.Caption will still work fine, and then you can introduce for example Button1.Caption.Wordwrap:=True.

    This is heaven for 3rd party component makers where you are forced to maintain backwards compatibility (code and dfm streaming), to avoid “polluting” classes with more and more items instead of subclassing / extending existing ones

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: