common foo {
asdf(qwerty(i+j));
printf(“%p”, write));
bar();
}
…(repeats verbatim 20 times)…
…
common foo {
asdf(qwerty(i+k));
printf(“%d”, (int)write); // cast to int
bar();
}
…
And then you could `mycc diff-common foo` and see:
<file>:<line>: common
<file>:<line>: common
…
<file>:<line>:
@@…@@
-asdf(qwerty(i+j));
+asdf(qwerty(i+k));
@@…@@
-printf(“%p”, write));
+printf(“%d”, (int)write); // cast to int
With this you can track named common blocks (allows using surrounding context like i,j,k). Without them being functions and subject for functional entanglement $subj discusses. Most common code gets found out and divergences get bold. IDE support for immediate highlighting, snippeting and auto-common-ing similar code would be very nice.
Multi-patching common parts with easily reviewing the results would also be great. Because the bugs from calling a common function arise from the fact that you modify it and it suddenly works differently for some context. Well, you can comment a common block as fragile and then ignore it while patching:
common foo {
// @const: modified and fragile!
…
}
You still see differences but it doesn’t add in a multi-patch dialog.
Not expecting it to appear anywhere though, features like that are never considered. Maybe someone interested can feature it in circles? (without my name associated)
I'm not convinced that automatic checking of copy-paste errors of such blocks make much sense though. At least I think the false positive rate would be way too high.
IIFE exist, but are cumbersome to type/read in most languages. C++ is probably the winner by syntax and semantics here.
false positive rate would be way too high
The key idea is not to have identical blocks, but to have a way to overview changes in similar code, similar by origin and design. It’s a snippet diff tool, not a typo autocorrector. There’s no false positives cause if “common foo” has zero diff in all cases, it probably should be “foo(…)”.
Regarding compound statements returning values: There are a number of languages which have that, including Rust. Ironically, it made me wish for a reversed form of the construct, i.e. something like
{ ...; expr } --> x;
// x is a new variable initialized to expr
I feel like this would help readability when the compound statement is very large.
I guess you’re asking about the block part — it’s a minor syntactic convenience and not the main point of the comment. It avoids the word function/lambda or def-block and related syntactic inconvenience like parentheses around and at the end and interference with ASI (when applicable).
Multi-patching common parts with easily reviewing the results would also be great. Because the bugs from calling a common function arise from the fact that you modify it and it suddenly works differently for some context. Well, you can comment a common block as fragile and then ignore it while patching:
You still see differences but it doesn’t add in a multi-patch dialog.Not expecting it to appear anywhere though, features like that are never considered. Maybe someone interested can feature it in circles? (without my name associated)