LWN.net Logo

Still no fixed template syntax

Still no fixed template syntax

Posted Mar 29, 2013 13:12 UTC (Fri) by HelloWorld (guest, #56129)
Parent article: A look at C++14, part 1

A major pain point in C++ template programming is the ambiguity between the less-than operator and the opening angle bracket for template parameters. That's what makes the typename and template keywords necessary in all kinds of crazy places.

It's 2013, Unicode has existed for ages and it's time to put it to use. They should allow proper angle brackets (unicode characters U+3008 and U+3009) for template parameters in addition to the conventional syntax.

template<typename T>
typename std::enable_if<T::template foo<42>::value, T>::type bla();
would become
template〈typename T〉
std::enable_if〈T::template foo〈42〉::value, T〉::type bla();
Much nicer.


(Log in to post comments)

Still no fixed template syntax

Posted Mar 29, 2013 14:27 UTC (Fri) by DDevine (subscriber, #60717) [Link]

Time to make a template...
Tappa tappa tappa... Oh crap, where's the angle bracket keys on my keyboard?

Code isn't about typography. If you like you could run your code through sed, and the rest of us plebs will use the greater than and less than symbols.

Still no fixed template syntax

Posted Mar 29, 2013 14:49 UTC (Fri) by heijo (guest, #88363) [Link]

Well you could just add keyboard bindings for them (e.g. on RightAlt+lessthan and RightAlt+greaterthan)

Still no fixed template syntax

Posted Apr 4, 2013 13:45 UTC (Thu) by dgm (subscriber, #49227) [Link]

Or you could glue two keys to the side of your keyboard, route the pins through the case to the PCI bus, write a custom kernel module, a driver for X, send patches to Qt and GTK+, and if you care, Microsoft.

Or you could just use < and >.

Still no fixed template syntax

Posted Mar 29, 2013 15:49 UTC (Fri) by tjc (subscriber, #137) [Link]

A major pain point in C++ template programming is the ambiguity between the less-than operator and the opening angle bracket for template parameters.

I agree. Having a language design gaffe like this at the lexical level really makes it a nuisance.

I don't really like source code that requires characters outside the 32-127 range, but if I did, I think my vote would be to use double guillemets, since they visually stand apart from LT and GT.

template «typename T»

I can't say that they're especially pretty.

Still no fixed template syntax

Posted Mar 29, 2013 16:40 UTC (Fri) by HelloWorld (guest, #56129) [Link]

I don't really like source code that requires characters outside the 32-127 range,
Many people don't. Most then complain about how it's hard to type (it's trivial, just add a suitable keyword binding) and how it breaks some tools (they deserve to be broken).

I think this really holds programming languages back. In fact, I think we should go much further than just embracing unicode characters. Mathematicians came up with all kinds of funny notations for sums, integrals, fractions, square roots and all that. The quadratic formula shouldn't look like this: x = -b + sqrt(b*b - 4*a*c)/2*a. It should look like this. And it really annoys me that we still don't have properly readable formulas in our programming languages because some guy in 1970 decided that ASCII was enough. It isn't.

Still no fixed template syntax

Posted Mar 29, 2013 16:57 UTC (Fri) by apoelstra (subscriber, #75205) [Link]

The quadratic formula shouldn't look like this: x = -b + sqrt(b*b - 4*a*c)/2*a. It should look like this.
The image that you linked to was generated by a LaTeX-like language. If programming languages could read LaTeX expressions, they would still be perfectly ASCII-able for those who want it, while others could use smarter text editors.

Still no fixed template syntax

Posted Mar 29, 2013 17:28 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, why not:
>мойТип тест(КАКАЯ_ТО_КОНСТАНТА);
>if(тест.открыть())
>{
> println("Відкрито.");
>}
BTW, that "i" in "Відкрито" is "i", not "i".

Still no fixed template syntax

Posted Mar 29, 2013 18:10 UTC (Fri) by HelloWorld (guest, #56129) [Link]

What's that supposed to demonstrate? Sure, I have no idea what that code is about. But I wouldn't know what, say, code written in czech is about either, so how does that make things worse for me? Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.

Still no fixed template syntax

Posted Mar 29, 2013 20:21 UTC (Fri) by tjc (subscriber, #137) [Link]

Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.

Well, maybe not:

http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

Still no fixed template syntax

Posted Mar 29, 2013 21:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

And that's exactly why one should stick to ASCII.

>Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.
No it isn't. Code in Russian looks very weird for Russian developers. Besides, Russian is a language with grammar cases and case-neutral identifiers are often very clumsy.

Still no fixed template syntax

Posted Mar 29, 2013 22:15 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> And that's exactly why one should stick to ASCII.
Uh, so one should stick to ASCII because one can screw up with or without unicode characters? Yeah right, that makes sense.

Still no fixed template syntax

Posted Mar 29, 2013 22:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

The problem is - I can fix screwups in ASCII.

Fixing non-ASCII code presents several additional and absolutely unnecessary problems. I don't know if you ever had a pleasure of editing code written in an unfamiliar script, but I had. Cut&pasting identifiers can only get you so far before you start crying.

Still no fixed template syntax

Posted Mar 29, 2013 23:08 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> Fixing non-ASCII code presents several additional and absolutely unnecessary problems.
Readability matters, and having keywords in crazy places for reasons that most C++ programmers don't understand doesn't help readability at all.

> I don't know if you ever had a pleasure of editing code written in an unfamiliar script, but I had. Cut&pasting identifiers can only get you so far before you start crying.
You must be really desperate if you need to come up with crazy use cases like that. I never needed to do what you described, nor did 99.9% of developers. Optimising a language for something like that would be insane.

Still no fixed template syntax

Posted Mar 30, 2013 12:36 UTC (Sat) by khim (subscriber, #9252) [Link]

I never needed to do what you described, nor did 99.9% of developers.

Rilly? Let's exclude developers who never worked in the international teams and never had to deal with foreign scripts. Do you still claim 99% of these like Unicode?

Most style guides forbid anything besides US ASCII even in languages where no such limitation exist for a reason. You only need to edit one piece of Java code which has Japanese-specific pieces with names in kanji and Arabic-specific pieces with names in abjad to understand why unicode in programming languages is bad idea (tm). At least if foreign names are transliterated you can least type them (even if you can not always pronounce them), but to even distinguish names in some weird scripts like abjad you need some training.

Even without kanji or abjad it's easy to create extremely hard-to-edit pieces of code. Here is an example:
public class HelloWorld {
  public static void main(String[] args) {
    for (int ⅰ=1;ⅰ<=10;ⅰ++) {
      for (int і=1;і<=10;і++)
        System.out.printf("%4d", і*і);
      System.out.println();
    }
  }
}

It's realtively easy to spot the error (depending on the font in your editor, of course), but if you try to fix it… you'll probably need to use copy-paste and if your piece of code contains not just “ⅰ” and “і” but a straightforward “i” and less straightforward “i” and also “ⁱ” and “ᵢ”, too… then you are in trouble. For java compiler all six are quite different but for programmer some of them may be hard to distinguish and some are impossible to distinguish at all (depending on font).

US Ascii also has couple of pieces where confusion is possible (think "O" vs "0" and "1" vs "l"), but these are well-known and fonts are often specifically designed to distinguish them. With unicode confusion is inevitable: I'm yet to see a font where “і” differs from “i” and often even “ⅰ” is indistinguishable from “і” or “i”.

The whole "let's argue about the taste of oysters with those who actually ate them" just make me sick. Sorry, but I've worked with programs which use Unicode and I most definitely don't want to repeat this experience. Unicode in comments is fine (even if you can not change them in a clean way you can always just replace them with some approximation and if code deal with a nuances of a foreign language then often you need to use a bit of unicode to explain what goes on there), but once Unicode reaches identifiers it becomes a disaster and I shudder to even think about them lever of mayhem when it'll reach the syntax of language itself.

Still no fixed template syntax

Posted Mar 31, 2013 13:57 UTC (Sun) by nix (subscriber, #2304) [Link]

I'm yet to see a font where “і” differs from “i”
FWIW, here, the former (CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I, according to uniname) is differently hinted, so appears slightly different (with more hinting blur) if the patented FreeType bytecode interpreter is turned on. (In my web browser, i FULLWIDTH LATIN SMALL LETTER I is invisible: in my terminals, it's visible since they use a different font, it is visible but ⅰ SMALL ROMAN NUMERAL ONE and ⁱ SUPERSCRIPT LATIN SMALL LETTER I are square boxes. IMNSHO, anyone who uses any of these when programming is a maniac. Even using them in literal strings or translated output is questionable: font coverage for these letters is just too poor.)

oops

Posted Mar 29, 2013 16:14 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Actually, it would become
template〈typename T〉
std::enable_if〈T::foo〈42〉::value, T〉::type bla();
(notice the lack of the template keyword before foo.

Still no fixed template syntax

Posted Mar 29, 2013 16:44 UTC (Fri) by simlo (subscriber, #10866) [Link]

No no no

Keep all code within ASCII!

OS'es for one reason do not agree on how to represent and show other characters.

Still no fixed template syntax

Posted Mar 29, 2013 17:07 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Every decent system out there is able to handle UTF-8 (that's because a system unable to handle UTF-8 isn't decent and should be dealt with by not using it).

Still no fixed template syntax

Posted Mar 29, 2013 17:29 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

My system can handle UTF just fine. It's _me_ that can't handle the full UTF character set.

Still no fixed template syntax

Posted Mar 29, 2013 21:03 UTC (Fri) by tjc (subscriber, #137) [Link]

Keep all code within ASCII!

I think I could get used to this:

template `(typename T)
std::enable_if `(T::template foo `(42) ::value, T) ::type bla();

Still no fixed template syntax

Posted Apr 2, 2013 12:02 UTC (Tue) by hummassa (subscriber, #307) [Link]

Backticks are the evilest ascii chars. :-D

Still no fixed template syntax

Posted Apr 2, 2013 8:53 UTC (Tue) by jezuch (subscriber, #52988) [Link]

Interestingly, early high-level programming languages separated the keyword and identifier namespaces by using e.g. bold or underline for keywords. This way the parser did not get a heart attack if you named your variable "if". (Some later languages dropped the inconvenience of special character attributes and made the keywords all-uppercase. And later still there was C.)

So, another way to fix the '<' ambiguity would be to make the template-initiating angle bracket bold ;)

Still no fixed template syntax

Posted Apr 4, 2013 13:48 UTC (Thu) by dgm (subscriber, #49227) [Link]

That's a bold proposal. Yes it is.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds