Inline-Variablen in 10.3 Rio werden als Fehler markiert

[romber]

Hallo! Habe gerade die 10.3 Rio installiert und wollte direkt die neuen Inline-Variablen ausprobieren. Klappt eigentlich ganz gut, nur wird "var" mitten im Code als Fehler markiert:

"Erwartet: END, aber VAR erhalten in Zeile..."

Habt Ihr das genau so?

[mkinzler]

Es wurde leider error Insight nicht an die neuen Features angepasst.

[Schokohase]

Zitat:

Zitat von romber (Beitrag 1418939)

Habt Ihr das genau so?

Ja siehe https://www.delphipraxis.net/1418650-post18.html

[romber]

Kann jemand sagen, ob es sich seit der Veröffentlichung etwas getan hat? Updates oder Hotfixes?

[Schokohase]

Ja, siehe https://community.idera.com/developer-tools/b/blog

[DieDolly]

Nach dem Patch werden Inlinevariablen trotzdem noch als falsch markiert.
Nicht immer aber in jedem Fall aber das Keyword

Delphi-Quellcode:

var

.

[Schokohase]

Zitat:

Zitat von DieDolly (Beitrag 1420956)

Nach dem Patch werden Inlinevariablen trotzdem noch als falsch markiert.
Nicht immer aber in jedem Fall aber das Keyword

Delphi-Quellcode:

var

.

Das hat auch niemand behauptet - weder ich noch die Sarina D in ihrem RAD Studio 10.3 Patches - December 2018 Blog-Beitrag

Ich verstand die Frage des TE so als ob er Informationen zu Updates und Hotfixes im Allgemeinen haben wollte.

[uups]

Gibt es mittlerweile irgendwas, ein Patch oder so, das dieses Problem aus der Welt schafft?
Bei mir ist Error Insight immer an, ohne größeren Probleme bis jetzt. Würde schon gerne die neuen Inline-Variablen nutzen, so wie das jetzt aussieht ist das aber eine Zumutung.

[MyRealName]

Ich wäre vorsichtig mit den Inline variablen. Ich hatte ein neues Projekt aufgesetzt mt diesen und am Anfang ging es auch ganz gut. Aber dann wuchs das projekt und ich habe seltsame Fhler bekommen. Aber nie wurden die variablen als Fehlerquelle angzeigt. Meist wa es am Schluss des Programms im finalization Teil (nicht meiner) wo der Debugger mir auch garnicht mehr zeigte, wo genau. Oft auch memory leaks, obwohl ich eigentlich beim Create immer gleich das Free mit dazu schreibe.

Ich habe 4 Tage seltsame Effekte gejagt. Sachen, die ich aus einem Tokyo projekt zu 99 % so übernommen habe, gehen auf einmal nicht mehr.

Irgendwann wusste ich nciht mehr weiter und habe die ganzen inline Variablen mal rausgenommen und in "herkömmliche" verwandelt und jetzt geht alles und ich habe weder leaks noch crashes beim Schliessen des Programms.

Von daher : Mit Vorsicht geniessen. Ich lass da erstmal die Finger von!

[freimatz]

Bei neuen Dingen immer erstmal zwei Version abwarten wenn man es einigermaßen stabil haben möchte.

[Der schöne Günther]

War ja mit XE7 und der revolutionären Möglichkeit Arrays mit dem Plus-Zeichen zu konkatenieren bereits auch nicht anders 🙄

[Sherlock]

Was natürlich den Nutzen dieser "Superdinger" noch mehr in Frage stellt. Ich bleibe dabei, daß "neumodischer" Krempel ohne tatsächlichen Mehrwert mal für ein Release einfach weggelassen und Fehlerbehebung Priorität 1A mit Sternchen haben sollte.

Sherlock
- man wird ja wohl noch träumen dürfen

[Dennis07]

Generell würde ich von den Inline-Variablen Abstand nehmen. Weiß offen gesagt auch keiner, warum Embarbadero plotzlich meinte die einfügen zu müssen. Zumal es echte Probleme gab oder Dinge, die wirklich gefehlt haben. Und die wurden nicht angegangen. Inline-Variablen selber sind sehr schlecht und unvollständig implementiert. Die impliziten Typen funktionieren auch nicht so, wie sie es sollten in einigen Situationen. Der Live-Debugger und Code-Insight unterstützen es noch nicht, da sie dummerweise ihren Castalia nicht upgedatet haben.
Generell ist der Mehrwert von Inline-Variablen und Typeninferenz aber auch mehr als begrenzt. "Ganz nett" in einigen wenigen Situationen wie Schleifenköpfen, aber meistens eher fehl am Platz in Pascal. Hätte man gern weglassen können.
Fazit: Einfach nicht verwenden

[Der schöne Günther]

Heißt das man kann die Variablen im Debugger nicht mehr auswerten - So wie die in anonymen Methoden "gecapturten" Variablen die es ja auch erst seit 10 Jahren gibt?

[Rollo62]

Zitat:

Generell ist der Mehrwert von Inline-Variablen und Typeninferenz aber auch mehr als begrenzt.

Hast Recht, aber "gut finden" tue ich die trotzdem.

Das Problem ist eher das EMBA solche neuen Features niemals bis zu Ende denkt.

[taveuni]

Zitat:

Zitat von Der schöne Günther (Beitrag 1424885)

Heißt das man kann die Variablen im Debugger nicht mehr auswerten - So wie die in anonymen Methoden "gecapturten" Variablen die es ja auch erst seit 10 Jahren gibt?

Bitte sag nicht dass dies in den neusten Versionen immer noch so ist?

[Stevie]

Zitat:

Zitat von taveuni (Beitrag 1424992)

Bitte sag nicht dass dies in den neusten Versionen immer noch so ist?

Leider ja, siehe RSP-9917 und RSP-22924. Es muss dem Debugger beigebracht werden, dass die nicht auf dem Stack sondern auf dem Heap liegen (als Feldvariablen der vom Compiler generierten Klasse für die anonyme Methode)

[uups]

Weiß jemand, ob das Problem mit dem Release 1 behoben wurde?

[Dennis07]

In den Release-notes steht es nicht. Zu erwarten ist es aber.
Da wir in der Firma sowohl 10.3 als auch 10.3.1 nicht verwenden werden (zu verbuggt, keine nützlichen neuen Features) werde ich das wohl auch nicht erfahren.

[AJ_Oldendorf]

Bestätigung:
Wird immernoch rot markiert (Wellenlinie) unter 10.3.1

[idontknow]

Und das beste ist: Refactoring funktioniert auch nicht mehr, wenn man inline-Variablen verwendet. Das funktioniert alles super bis zu der Methode, in der das erste Mal inline-Variablen verwendet werden, ab da bis zum Ende der Datei lassen sich z.B. keine Variablen mehr umbenennen. Hat mich einige Zeit gekostet, bis ich den Zusammenhang hergestellt hatte. Ist übrigens mit 10.3.1 auch nicht anders...:(