David Schwartz 426 Posted March 10, 2020 I'm curious if anything has been said about language enhancements in 10.4. I tend to avoid language enhancements, but I'd love to see nullables as well as a ?? and ??= operators, and even a ternary ( x ? y : z ) operator, esp a ternary operator that works with nullables. I've seen that nullables are in the pipeline, but the overviews are getting so high-level that it's nearly impossible to discern any specifics. 1 Share this post Link to post
Darian Miller 361 Posted March 10, 2020 I've collected some info on 10.4 here: https://github.com/ideasawakened/DelphiKB/wiki/D27.Next.10.4.0.0 Specifically, managed records was pushed off for 10.4: http://blog.marcocantu.com/blog/2018-november-deferring-managed records.html And it was confirmed recently as coming in 10.4: https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription That's all I've seen specifically for language enhancements in 10.4.0 but they may surprise us. I'm looking forward ti VCL Styles + High DPI improvements in 10.4. The language server protocol will likely open up a new set of tooling for the IDE, which might be cool if it works. Beta should start 'very soon' - supposedly sometime in March. 1 Share this post Link to post
Fr0sT.Brutal 900 Posted March 10, 2020 @David Schwartz what do you need nullables for? I only face them when dealing with DB but there are nullable Variants already Share this post Link to post
Lars Fosdal 1791 Posted March 10, 2020 I am really looking forward to nullable base types. Variants sort of work, but you have to write a lot of checking code that could be made less complex with nullables + operators + validation. Some food for thought here: https://developers.redhat.com/blog/2020/03/05/c-8-nullable-reference-types/ 1 Share this post Link to post
Sherlock 663 Posted March 10, 2020 I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables. Considering the code name "Denali" is based on a mountain in Alaska a feature freeze could sound likely, but I doubt it. When Delphi Anchorage is finally released it will have some cool new features along with the obligatory cool new bugs... *Sigh* 1 Share this post Link to post
Lars Fosdal 1791 Posted March 10, 2020 No feature freeze until Delphi Antarctica 1 3 Share this post Link to post
David Heffernan 2345 Posted March 10, 2020 46 minutes ago, Sherlock said: I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables. The eternal optimist 2 1 Share this post Link to post
Sherlock 663 Posted March 10, 2020 Just now, David Heffernan said: The eternal optimist That's me 1 Share this post Link to post
Arnaud Bouchez 407 Posted March 10, 2020 The main change about the language would be the full ARC removal. The memory model is really part of the language, to my understanding. It is just as vital as to operate with "class" itself. Pure unfair FUD trolling remark: managed records are available in FPC trunk since a few months, and I guess EMB doesn't like to be behind an Open Source compiler. 😉 We implemented Nullable types using variants, and integrated support in our ORM. It has the advantage on working since Delphi 6, with low overhead, and good integration with the pascal language. See http://blog.synopse.info/post/2015/09/25/ORM-TNullable*-fields-for-NULL-storage - back from 2015! 2 Share this post Link to post
Markus Kinzler 174 Posted March 10, 2020 (edited) Managed Records were removed at last minute for 10.3 and postponed to 10.4 Edited March 11, 2020 by Markus Kinzler I meant records 1 Share this post Link to post
Sherlock 663 Posted March 10, 2020 48 minutes ago, Markus Kinzler said: Managed Reports were removed at last minute for 10.3 and postponed to 10.4 You either mean management reports or manged records... not sure which. Hmmmmm 1 Share this post Link to post
Clément 148 Posted March 10, 2020 3 hours ago, Markus Kinzler said: Managed Reports were removed at last minute for 10.3 and postponed to 10.4 I'm not the only one who runs out of coffee! . Share this post Link to post
Stefan Glienke 2002 Posted March 10, 2020 6 hours ago, Arnaud Bouchez said: We implemented Nullable types using variants, and integrated support in our ORM. It has the advantage on working since Delphi 6, with low overhead, and good integration with the pascal language. See http://blog.synopse.info/post/2015/09/25/ORM-TNullable*-fields-for-NULL-storage - back from 2015! Not typesafe, thank you bye. Share this post Link to post
Stefan Glienke 2002 Posted March 10, 2020 10 hours ago, Lars Fosdal said: Some food for thought here: https://developers.redhat.com/blog/2020/03/05/c-8-nullable-reference-types/ That is nullable reference types which is a completely different beast and took the compiler and language guys at Microsoft a significant amount of time to get it right. Share this post Link to post
Darian Miller 361 Posted March 10, 2020 7 hours ago, Arnaud Bouchez said: The main change about the language would be the full ARC removal. The memory model is really part of the language, to my understanding. It is just as vital as to operate with "class" itself. Ah yes, I neglected to mention ARC removal in my summary. I guess I assumed that one was well known as coming in 10.4 Share this post Link to post
Arnaud Bouchez 407 Posted March 11, 2020 (edited) 20 hours ago, Stefan Glienke said: Not typesafe, thank you bye. What do you mean? That you can put a string to a TNullableInteger? At least under FPC they are type safe: you are required to call NullableInteger(1234) to fill a TNullableInteger variable - you can't write aNullableInteger := 'toto' - or even aNullableInteger := 1234. Delphi is more relaxed about implicit conversions, so under Delphi it is indeed not typesafe, since you can write aNullableInteger := 'toto'. Edited March 11, 2020 by Arnaud Bouchez Share this post Link to post
Fr0sT.Brutal 900 Posted March 11, 2020 TNullable<T> = record public Value: T; IsNull: Boolean; class operator Implicit(const Val: T): TNullable<T>; class operator Explicit(const Val: T): TNullable<T>; end; ? Share this post Link to post
Stefan Glienke 2002 Posted March 11, 2020 (edited) 3 hours ago, Arnaud Bouchez said: What do you mean? That you can put a string to a TNullableInteger? At least under FPC they are type safe: you are required to call NullableInteger(1234) to fill a TNullableInteger variable - you can't write aNullableInteger := 'toto' - or even aNullableInteger := 1234. Delphi is more relaxed about implicit conversions, so under Delphi it is indeed not typesafe, since you can write aNullableInteger := 'toto'. Interesting - even with {$mode delphi} it does not allow that - probably it's yet another of those bazillion switches of FPC to make it behave similar to Delphi - not that I would ever care. Anyhow this is still a thread about Delphi so your approach is not sufficient here imo. @Fr0sT.Brutal It's a little less simplistic than that but basically yes. Edited March 11, 2020 by Stefan Glienke Share this post Link to post
David Schwartz 426 Posted March 11, 2020 (edited) I don't care about nullables so much as a more efficient way of writing code that tests for a NIL value and stops rather than raising an exception, so you don't need to have if Assigned( xyx ) then all over the place to prevent exceptions. Nullables seem like a back-door way to get support for something that would save quite a bit of time and coding that isn't going to be added to the language just because it's really useful. There are so many idiomatic phrases we use habitually simply because the language never supported ways to avoid them originally; other languages are finally being enhanced to address things like this, but Delphi remains stuck in the Dark Ages when it comes to useful language enhancements. Like the use of strings on case statements that practically every language in use today supports, just not Delphi. Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS. It's like saying you'll never put an electric starter on your cars because it's just not historically accurate with original car designs. So you have to get out and crank a lever in the front of the car to get the engine started. I don't know about anybody else, but I'm sick and tired of hearing off-the-cuff comments from managers and VPs who make technology usage decisions saying that Delphi old and stale so they can't wait to replace their code with "a more modern language". At the place I started working at in mid-January, the CTO cornered me one day after I'd been here about 3 weeks and said, "So how much work do you think it would take to replace all of the Delphi and MySQL with C# and SQL Server?" Why is this such a pervasive and recurring question everywhere I've worked for a decade? There may be something heart-warming about the fact that Delphi can compile code written in 1995, but it's keeping management teams at corporations of all sizes from embracing Delphi because there are plenty of language enhancements in C, C++, C#, Python, Ruby ... you name it, that are not in Delphi, and from all indications will never be. That gives the clear impression that Delphi is old, stale, stodgy, and is something nobody wants to use because it has no support fo the latest language features that other languages have. For 12 years now, I've worked at one place after another where my job was to keep a bunch of legacy Delphi code alive until they can replace it with "something more modern". That's THEIR words, not mine! And I have absolutely no defense for it. They use the Pro version of Delphi, not Ent or Arch, because they don't use any of the other stuff bundled with the bigger packages. Just the language and a few 3rd-party component libs (mostly free stuff). There are other tools that implement Pascal variants that are almost totally compatible with Delphi, and add plenty of new language features that are on-par with contemporary languages. These prove it can be done elegantly and cleanly. But the compiler builders need the motivation to do it. If the folks who own Delphi ever hope to get it mainstream again, they need to bring the language into the 21st century and add features that most other contemporary languages have had for a while now. But when the topic comes up, all we ever hear is crickets. "Oh, but look at all the work we've done with our latest Interbase enhancements!" There's lots and lots of work being done enhancing stuff that hardly anybody uses. But enhancements to the core product are nowhere to be found. Edited March 11, 2020 by David Schwartz 5 Share this post Link to post
Stefan Glienke 2002 Posted March 11, 2020 (edited) 11 minutes ago, David Schwartz said: Compilers are supposed to make the work of programmers EASIER. I don't subscribe to notions that "we don't do that because it's not in the 'spirit' of Pascal" or whatever. That's just BS. YES, exactly that! However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape. Like using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords or introducing inline variables (that had many bugs) without the entire tooling understanding them and stopping to work. So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff" Edited March 11, 2020 by Stefan Glienke 2 Share this post Link to post
David Schwartz 426 Posted March 11, 2020 1 minute ago, Stefan Glienke said: YES, exactly that! However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape (such as using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords). So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff" As if that has never happened with anything Microsoft ever published ... Share this post Link to post
Stefan Glienke 2002 Posted March 11, 2020 Just now, David Schwartz said: As if that has never happened with anything Microsoft ever published ... VS is also not perfect but their compiler and language design is rock solid - yes, if you look into C# communties there are also people complaining that stuff is not C#-ish and that but the number of times where the C# compiler just craps itself, kills the entire IDE or simply produces completely wrong code is like several orders of magnitudes less than with Delphi. 1 Share this post Link to post
Uwe Raabe 2057 Posted March 11, 2020 27 minutes ago, Stefan Glienke said: "fix the existing bugs before adding new broken stuff" Actually I don't need new broken stuff at all - regardless of existing bugs being fixed or not. 1 1 Share this post Link to post
Stefan Glienke 2002 Posted March 11, 2020 2 minutes ago, Uwe Raabe said: Actually I don't need new broken stuff at all - regardless of existing bugs being fixed or not. https://en.wikipedia.org/wiki/Hyperbole 1 Share this post Link to post