Kryvich

@Attila Kovacs OK I found them too in TEditorActionLists. I do not think these are some "secret" functions. As I understand, they move cursor to the previous/next line in the editor, marked as modified (yellow bar) or saved (green bar).

Still, it is not clear why the compiler did not issue a warning about an unassigned Result. I minified the code to make it clearer. program TestUnassignedResult; {$APPTYPE CONSOLE} type TRec = record Data: Byte; function NS: TRec; end; function TRec.NS: TRec; begin Writeln('I''m in NS'); // W1035 Return value of function 'NS' might be undefined <-- not showed!!! end; begin //.. end.

Yes, I used "Go to next difference" / "Go to previous difference" on the tool bar (34s - 42s on the video). I did not found any special buttons for "Next Unsaved Modification" / "Previous Unsaved Modification". You should compare Buffer and File to see unsaved modifications. Having said that, I should note that I usually use a third-party utility for text comparisons: Compare-It. It allows not only to compare, but also to modify files if necessary.

Works for me:

@Attila Kovacs Fair remark. I made this conclusion from the article (see GIF above). In fact, I did not know that these icons can be turned off (Tools | Options | Editor options | Display | Show image on tabs). Looks even better, thank you for the tip! In addition to 10.2.3 CE, I have XE2 and older versions here. I do not have access to Delphi XE3 - 10.2.2. So if you're interested, I can try to recompile the package for the Delphi XE2. The plan for my future open-source and free projects is to move to 10.3 Community Edition when it will be available.

One more possibility with const parameter and a predictable behavior: procedure Test2(const [Ref] rec: TTestRec); begin rec.Change( 2 ); Writeln('Inside Test2: ', rec.Value ); // 2 end; http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Parameters_(Delphi)#Constant_Parameters

A few suggestions for the post layout in the desktop version of community: Shift the icon a little higher Remove "Members" Optionally remove the reputation and posts number, we can see this information by hovering mouse over the icon. Move the blocks as showed by the arrows. People who came from Google+, are accustomed to a light design without optional elements. Thank you for the forum, it can be the best place for communications!

@rvk They can remove only "members" and leave others as is. This is how it is implemented on G+.

@Uwe Raabe Ouch! The behavior depends of record size.

@Cristian Peța After a complete rebuild, hints began to appear lightning fast. I suppose, until the project was fully compiled, IDE ran the background compiler each time it tried to show a hint. That is why the freezes occurred. This can be solved by putting the code completion into a separate thread.

@Schokohase But if you check the value inside Test2: rec.Change( 2 ); Writeln('Inside Test2: ', rec.Value ); // 2 Now I understand why they use var instead of const in the constructor: the const record parameter passed by value, not by reference.

@Cristian Peța I've change it like this: Pointer(buf):=@buffer[kk]; And yes, too much of hints and warnings. But as a test sample for IDE developers is great.

Thank you for mentioning a really big open-source project that I can test on my Delphi 10.2.3 CE. Yes, the same thing happens to me. (IDE FixPack installed.) It would be nice if Delphi developers tested their product on this project. (6 minutes to rebuild the project is a record for me.) At yesterday's webinar "See What’s Coming in 10.3 Rio", they mentioned that the code completion in the new C++Builder will work in a separate thread and not block the editor. I hope they can later implement this function in Delphi too.

@Uwe Raabe True remark. It is important that the source variable itself is not changed, so it must be declared as const.

@Cristian Peța Yes, but the source can be constant, or a constant parameter of a method. procedure TestRec(const DoNotChangeMe: TManagedRecord); begin ... var tempRec := DoNotChangeMe; ... end;

At today's webinar, new custom managed records in Delphi have been shown. There was such a declaration: And the implementation of operator Assign: class operator TMyRecord.Assign(var Dest: TMyRecord; var Src: TMyRecord); begin Dest.Value := Src.Value; end; Is there an error here? Perhaps it would be more correct to write const Src: TMyRecord? Because the above declaration allows you to change the Src variable: Src.Value := Dest.Value; Even better it would be to write it as class operator TMyRecord.Assign(const Src: TMyRecord): TMyRecord; begin Result.Values := Src.Value; end; And prohibit to change the variable Result itself (it's preallocated).

Yes, I get it. Just kidding. In small companies where I worked, the above usually happens.

@David Heffernan Pascal was designed by Wirth with a Static Strong Safe typing in mind. The proposed compiler warning follows this concept. It can help prevent some semantic errors and write a clean code, without the need to complicate a code by introducing new structured types. So It's good for Delphi programmers and for Delphi, a win-win situation.

Who sweeps your office floor? :)

It's interesting that for spawned class types there is a special type check: type TApple = class end; TOrange = type TApple; // Identical inside but not the same semantically procedure TestApplesAndOranges; var apple: TApple; orange: TOrange; begin apple := TApple.Create; orange := apple; // <-- [dcc32 Error] E2010 Incompatible types: 'TOrange' and 'TApple' end; Great! Update: But: orange := TOrange.Create; // E2010 Incompatible types: 'TOrange' and 'TApple' orange := TApple.Create; // E2010 Incompatible types: 'TOrange' and 'TApple' Hmm. So what is the orange that I have declared? We can find out like this: var orange2: TObject; ... orange2 := TOrange.Create; ShowMessage(orange2.ClassName); // 'TApple' This is the correct answer (the classes are the same inside). Only it is not clear why orange := TOrange.Create; does not compile...

Yes, wrapping to the record type is possible. Though having the [optional] strong type checking for these types would be better. Detecting a possible error at compile time is much better than at runtime, right? The language already has everything to implement this: type // Aliases, no type checking on assignment TDistanceMeters = Double; TDistanceMiles = Double; // New custom types, [optional] type checking on assignment is needed TDistanceMeters = type Double; TDistanceMiles = type Double;

But will this be the right solution? These types have different sizes (tested for Win32): if SizeOf(Pointer) <> SizeOf(TWndMethod) then ShowMessage('No way.'); // 4 <> 8 I tried this: var i64: UInt64; ... i64 := fld.GetValue(TabSet1).AsUInt64; proc := TWndMethod(i64); But get Exception EInvalidCast 'Invalid class typecast' for GetValue.AsUInt64. Update. I did it like this: var p: Pointer; ... p := fld.GetValue(TabSet1).GetReferenceToRawData; proc := TWndMethod(p^); Thanks @Lars Fosdal for the hint!

Exactly! Let this check be disabled by default. Actually Unicode strings (WideString type) existed before converting VCL to Unicode. Try it in Delphi 2007 - no warnings, but there is conversion error: procedure TestAnsiWideString; var ansiStr: AnsiString; wideStr: WideString; begin wideStr := #1055#1072'-'#1073#1077#1083#1072#1088#1091#1089#1082#1091#13#10 + #12498#12517#12540#12473#12488#12531#12289#31169#12383#12385#12395#12399#21839#38988#12364#12354#12426#12414#12377#12290; ansiStr := wideStr; if wideStr <> ansiStr then Writeln('Houston, we have a problem.') end; But they added the Ansi <---> Unicode check, because it became a massive problem when moving to Unicode.

@Arnaud Bouchez If someone don't care about the strong typing, these hints and warnings can be mooted selectively, locally for a code block or globally for a project. {$WARN STRONG_TYPE_CHECKING OFF} They have already added improved type checking for string types when there is an implicit ANSI <--> Unicode conversion: [dcc32 Warning] W1057 Implicit string cast from 'AnsiString' to 'string' It is very useful in many cases. So I see no problem adding the same check for other simple types, the built in ones or created by the user. As for type helpers, the compiler might allow their use for spawned user types if the strong type checking warning I suggest is disabled.

@David Heffernan No need to change the language. We need a small revision of the compiler so that it shows a hint or warning. Such checks can be added to a third-party tool similar to FixInsight. But having additional type checking right in the compiler would be much better.