Stefan Glienke

@Arnaud Bouchez I know you like to deal with low level stuff but being able to be more declarative about loops and other language constructs is a benefit imo. That var passing of the loop variable is bad, but Primoz wrote that just for fun and advised not to use it. I guess every Delphi developer knows how a while or repeat loop works but I have seen enough off by one errors caused by counting the loop variable wrong, messing up the loop condition or other stuff which could just be eliminated if the language itself could treat it right without the need to put extra abstractions ontop that just make code slower.

Another thing that just applies to 10.3 though is that only in a for loop you can inline declare the variable to only be valid in the loop scope and not outside.

Better than releasing something that is broken and makes all your code fail, amiright?

The joys of packages as a library author. Looks like commit ace9e54 only modified the 10.2 package.

That commit removed the following files:

MARS.Client.Messaging.Resource.pas
MARS.Client.SubResource.JSON.pas
MARS.Client.SubResource.pas
MARS.Client.SubResource.Stream.pas

Just remove them from the contains in the MARSClient.Core.dpk and you should be able to compile.

The second parameter of the Assign operator actually has to be either var or const [ref].

Wow they are still (happened on the old forums as well) leaking email addresses in the usernames as they seem to be generated from the email used on the old community page ... 

I am sure using the type keyword after the equals sign was not part of the original pascal syntax and is only there to let the compiler produce a new typeinfo instead of it just being an alias that still points to the exact same type.

1 minute ago, Kryvich said:

A small hint from the compiler would help avoid difficult-to-find errors.

Agreed, type redeclaration is really not very helpful in many situations.

- you still have implicit type compatibility no matter what

- but helpers stop working

6 minutes ago, Kryvich said:

In the right pascal way it would be like this:

And after that you show why the "right" way is bad...

An URL consists of different parts which combined give a string, yes but should be represented as the different parts, hence the record.

Especially since there are cases where such a type cannot just be represented as string or number but consists of different data of different types. Yes there might be a string representation but it should not be passed as that through your API.

It will not get them more customers just because it's 64bit and runs out of memory later because all the instabilities and the compiler getting into a bad state because of compile errors or what not crashing the IDE will still be there as will the poor code tooling.

Going the easy/cheap way every time is what puts Delphi and the IDE into the current situation of constantly having to react to external factors and tinker around edges.

On 11/1/2018 at 12:38 PM, David Millington said:

We use it internally, daily,

Sometimes I really have a hard time believing that or you just avoid certain features or have subconsciously developed a certain habit to do things differently.

Or you just use it to prepare demos.

The benefit of the TUrl type opposed to differently named overloads is also that you declare a domain type and make the API cleaner than just (string, string, string) regardless the naming of the parameters

Well you have a different definition then than Intel in paragraph 8.1.1 it seems.

So unaligned data can be as well part of a struct/record which fits into a cache line and thus is guaranteed to be atomic.

40 minutes ago, David Heffernan said:

unaligned access of data greater than a single byte is not atomic

isAtomic := not IsCrossingCacheLine(unalignedData);

On 11/4/2018 at 12:07 PM, dummzeuch said:

I wonder whether the same problem exist in Delphi 10.3.

Get into the beta - I guess being a maintainer of one of the most noticeable IDE plugins might help even if you are not on subscription personally.

@Marco Cantu @David Millington might be helpful with that.

On 11/7/2018 at 10:03 AM, Lars Fosdal said:

I wouldn't mind a 64-bit IDE down the road.

Yeah, then the IDE can more excessively waste memory left and right until your RAM is used up instead of crash early, brilliant idea...

Throwing more memory at an application that does not know how to properly manage memory is not the solution.

Oh, please, no excuses about the compiler leaking memory because of LLVM, if you know that then don't load it into the IDE process.

Ah, that has to be done to use it for IDE tooling, like code completion and all kinds of source related things.

Now you see why other languages and IDEs go the way of separating this and using a language service to provide such information

That fact that you have to mark overloads to a virtual method as reintroduce always bothers me but I never cba to actually report it.

4 hours ago, Emil Mustea said:

Better: with inline declaration will stay alive until the block end, not until routine end.

And how exactly can we call Add on that "New" record if 

7 hours ago, Emil Mustea said:

there is no need for default property/member lifting

?

52 minutes ago, Cristian Peța said:

Perhaps that New record must also be declared next to s1. Otherwise how can it go out of scope? 

Well, New.Of could return a record that has implicit operator overload to be assignable to the s1 variable which then implicitly goes out of scope at the end of the routine.

3 hours ago, Johan Bontes said:

It seems Roman Yankovsky has not had time to integrate all my issues yet. 

It is very unfortunate that you used merge to get the latest master changes into your fork rather than rebasing.

That makes looking at your changes very difficult (I had to look back through the commits until I found yours that were not integrated into master via PR).

Also having all changes in one branch will result in some huge PR whereas putting each different change into it's own branch and submitting PRs for that would be easier to review.

I don't know about Roman but I would not accept a PR with a ton of different fixes where I cannot separate them from each other and validate them individually.

I just bring this up because I want those bugfixes incorporated back into the main project.

3 hours ago, Attila Kovacs said:

Even if it breaks your Uses Helper for long time?

It will only break it as long as DelphiAST does not support the new syntax 🙂

Using that feature in code that also needs to compile in versions before 10.3 makes no sense - however once we migrate to a version that has this feature I will use it in company source code with great joy.

46 minutes ago, Cristian Peța said:

IShared<T> is nice but a little convoluted

It has the overhead of being an interface, causing heap allocation and doing a call every time you access it. In 1.3 there will be some optimizations to reduce that. The only solution that will not cause all this is the one I described previously.

The difference is the implementation, why put something into TObject which is then turned off for everything unless I need it. This is already the case for TMonitor which is kinda arguable. Putting the RefCount field into every single object instance only wastes memory.

So if you are for explicit opt-in it not being part of TObject itself is way better.

So if we get records that are not running through InitRecord, CopyRecord and FinalizeRecord but directly call their constructor/destructor/copy operator you get rid of all that overhead and don't need records wrapping interfaces (no heapallocation needed as well). If we then possibly also get a way to do operator lifting/hoisting we get rid of the current need to write .Value when accessing the stored value (which is why I wrote IShared<T> where you don't have to).

If you haven't watched this before it might make it a bit clearer what it means to have modern compiler architecture and what benefits you get from it (like not having to implement everything twice for compiling itself and for tooling):

2 hours ago, Stregor said:

Why not go one step further and allow initializing local variables?

Because that would only make initializing with const values possible and not like now initializing with function results.

So I guess their reasoning was to not extend existing variable declaration in a very limited way but go the full distance.

2 hours ago, Cristian Peța said:

I don't understand what would be wrong to enable ARC for objects and to consider [unsafe] as default. It will not brake old code. And using [safe] or [arc] we can have automatic memory management. At least for simple scenarios.

It would be wrong in the same way as most of the time it is wrong to mix object and interface references because as soon as interface reference is triggering ARC your instance might be prematurely destroyed.