Inlining-declarations: destroys the readability, & organization in the language.
Pattern-matching: Not a fan, to many bad experiences w/ RegEx, and I anticipate the feature will be used inappropriately… like trying to parse HTML with RegEx.
A lot of these come off as “But, mom! All the cool kids are doing it!”
I don’t have gripes with normal strings, just with the use of untranslatable string constructions. And f-strings are making things worse not better.
As I remember, you can write 碱螽 in your code even for procedure names, in comments… with the right switch (maybe -gnatW8 and/or pragma Wide_Character_Encoding (UTF8);). And use Wide_Wide_String in your code :-> Or VSS.
The syntax is essentially irrelevant, the underlying concept is shaky ground ; and if we’re going to be very particular about it, this is more similar to PHP’s strings than C… but in either case (this, string-interpolation; or C’s format-strings) that underlying concept is treating strings as templates and “filling in” the holes.
A proper templating system could be such that it enforces type-correctness in its parameters unlike (e.g.) C’s format-strings, and it would also force a bit of care into what that value is — string-interpolation, OTOH, encourages sloppiness, while format-strings are typically type-unsafe and treat what is essentially unstructured (plain-text) as if it were structured, and imposing data that ought to be structured into that.
(Unix/Linux’s stream-system and ad hoc processing/piping is an excellent illustration of how the unstructured nature of plain-text, despite being easy, imposes much work downstream, as well as security/safety issues: consider processing output from some utility, always grabbing the fourth column’s number and processing it… you’ve never seen this be anything other than a positive number, so you code on those assumptions… now, what happens when it gives you a zero, a negative number, or some non-digital text-value? — Because the utility discards all type-information in its display, you cannot depend on that being caught and must account for the possibility, at every step in your chained-together pipe-construct… of course, like checking that the buffer is not overflowed, this is optional and manually tedious in C.)
I think importing (or catering to) such mindsets is foolish and counter to Ada’s design-goals.
Actually I would say in the case of the formatted string, the syntax is really important. The big risk with printf in C (note that the C language does not have format strings at the language level, the printf function specifies a format but it is its own format and not a language level construct). comes from the fact that printf inserts type information into the format itself and then relies on the programmer to ensure that the inputs used have matching type information. When a mismatch happens you get really bad stuff sometimes.
The format strings AdaCore is proposing don’t make the mistake of inserting type information into the format string itself, which makes it much safer because the Ada compiler can then verify the type of the input before it is converted to a string (so for the above example, in Ada you would declare the variable holding the column as Positive and it would catch a negative number and thrown an exception before the format string is even built).
There’s definitely room to argue/discuss how it feels/looks and whether it leads to sloppy programming or not, but I don’t think it has the same safety issues due to how Ada’s type system works and how the format string specification leaves out type information, allowing language constructs to pre-verify before construction.
It might be worthwhile to gen up some examples of where safety is compromised with the format string syntax AdaCore is using? That could be good material to engage in discussion with them over it. I don’t know of any offhand, but I hadn’t put a lot of time into it yet. Maybe someone with more experience can come up with some.
Inlining-declarations: destroys the readability, & organization in the language.
Only pro I could think of, is that objects would only be allocated when used, not before. But isn’t already already optimized ? I don’t think that change to the object code, right ? Can someone confirms if there is an difference in assembly between this and that ?
I would expect the declaration to be delayed until actually needed in the code, even with an initialization. But maybe I’m expecting too much ?
procedure Main is
object1: Integer;
begin
delay 30.0;
Object1 := 40 000;
end main;
procedure Main is
begin
delay 30.0;
declare
object1: Integer;
begin
Object1 := 40 000;
end;
end main;
I guess that with a f"a = {a}", the compiler will see {a}, extract the variable name, get the relevant Image function and compile "a= " & Integer’Image(a) if a is an integer.
It is type safe (no risk of type mismatch like in C). The only drawback is the absence of redundancy like in Ada. But are there many risks of errors ?
Note: OCaml has a type safe formatting system. It looks like C… but the type consistency is verified at compile time.