Kryvich

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.

If you like my Forms Humanizer for Delphi IDE, I have something new for you and other colleagues. It's a new free plug-in for Delphi 10.2.3 IDE, which shows the status of opened files in the form of colored bars in the tabs above the editor:

If you are interested you can download and test it here: https://sites.google.com/site/kryvich/kryvichs-editor-status-bars

It is interesting that as follows from the article "New in 10.3: IDE UI Improvements in the Main Window", an appearance of the file tabs in the new Delphi 10.3 will change significantly:

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

@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.

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!

@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.

I can do it without RTTI, but get a compiler error when using RTTI:

procedure TForm1.Button1Click(Sender: TObject);
var
  ctx: TRttiContext;
  rt: TRttiType;
  fld: TRttiField;
  proc: TWndMethod;
begin
  proc := TabSet1.WindowProc; // Compiles and works OK without RTTI
  ctx := TRttiContext.Create;
  try
    rt := ctx.GetType(TControl);
    fld := rt.GetField('FWindowProc');
    ShowMessage(fld.GetValue(TabSet1).TypeInfo.Name); // 'TWndMethod'
    if fld.GetValue(TabSet1).IsType<TWndMethod> then    // True
      proc := fld.GetValue(TabSet1).AsType<TWndMethod>;
      // E2010 Incompatible types: 'procedure, untyped pointer or untyped parameter' and 'TWndMethod'
  finally
    ctx.Free;
  end;
end;

Any suggestions?

@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.