especially if they're only syntactic sugar on steroids or some alias for an existing feature (like your inout suggestion (see below)).
I am out (pun intended) of ways to explain that
inout isn't syntactic sugar. You guys are mixing two things that are independent of each other. One is to let the compiler know if something should be passed by value or by reference and the other is to let the compiler know
how that variable will be used, is it read-only, is it write-only or read-write ? (obviously applicable only to variables passed by reference)... if the compiler had that information then it can do better error checking. Instead, you guys have associated
var with initialized variables because, since it is a common mistake, you wanted to warn the programmer when the variable isn't initialized. The result: piles of worthless compiler messages and incorrectly redefining the semantics of
var. Niklaus Wirth made the purpose and semantic scope of "var" quite clear in its Pascal report but, even that doesn't seem to get across.
I am not going to explain it again. As Einstein said, insanity is to do keep doing the same thing and expecting a different result.
They allow for code like this:
var
p: PLongInt;
begin
p := GetAPLongIntFromSomeWhere;
while p^ <> 0 do begin
DoSomethingWithP(p^);
Inc(p);
end;
end.
Maybe I'm missing your point but, I don't see anything in that code that can't be accomplished using standard Pascal constructs. That said, I do find the feature convenient (C/C++ pollution). The reason I brought it up is because when someone uses (and misuses) the argument "it's already there" (even when it isn't, as you do with
inout) then it is one of the constructs that serves to show how hollow that argument is.
The problem is reality: var is used in the way that users read the passed in value (aside from legacy code which used var because out didn't exist yet) and there have been enough users bitten by not-initialized variables passed to var parameters that it was more useful to add a warning so that they wouldn't fall into that trap.
The reality is that, in an effort to help users avoid a common mistake, you guy made another one. You created an association that neither exists nor should be there. And in sort-of solving one problem (uninitialized variables) you created another one: piles of useless messages that get in the way and bury genuinely useful messages that are now difficult to spot because of all the unnecessary junk the compiler is outputting. I give you credit for good intentions but, it paved a path to message overload hell. That alone should make you guys reconsider that decision.
Microsoft opened up the PDB format when they worked on clang so that they can use it as a frontend for their code generator backend (see here).
I had seen that and, to use that to state that MS opened up the PDB format is, IMO, a bit of an overstatement. As it says there, that thing doesn't compile and if someone wants to have their compiler output MS debug symbols in a PDB, even with that, they have a good (and not easy) way to go.
Another thing that I find interesting, apparently the LLVM guys put in the additional work needed to fully reverse engineer the PDB format but, one thing that seems missing is, usable documentation from _them_ showing how to use the PDB format.
MS paid lip service to "opening the PDB" format. They threw a bone (better than nothing) and the dog that got the bone seems to have quietly kept it for itself.
It would literally be great if the VS debugger could be used - with full symbolic information - to debug FPC executables. Now, I'm really dreaming, if it could limit the output to the subset used in old PDBs then, FPC 32bit executables could be debugged with Softice. Only St. Peter has something better to offer than that.
Now, if St. PascalDragon would get rid of the incorrect association of var with initialized variables, that would be pretty good, it would definitely pave the way to eventually meeting St. Peter with a smile.
I am grateful for 440bx's suggestion. I just implemented the scope block. Although the scope block itself was already on my feature list, the exit ability was not.
I'm pleased to see control-flow features implemented in a language. They really help simplify algorithms. As far as the question you had about which scope break acts on, it's always the scope that contains it. Just like break in any loop, the difference is, the scope doesn't loop over anything, it just delimits a group of statements. The part to be careful about is carefully defining which statements create a scope, if that isn't precisely defined then it can result in ambiguities.
Recent
