Andrei Alexandrescu wrote: > Walter Bright wrote: >> KennyTM~ wrote: >>> Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's >>> primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In >>> practice, the most important case is the sum from 1 to n, which is an >>> extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly >>> ugly for something so fundamental. It's so ugly that noone uses it: >>> you always change it to n*(n+1)/2. But then, n gets evaluated twice. >> >> As amply illustrated, one can make this argument pro and con about any >> builtin operator. The waterfront real estate of builtin operators is >> extremely limited, so we need to be very parsimonious in allocating >> it. Candidates for builtin operators need to have a very high bar. >> >> The question is, does ^^ clear that bar or not? > > In order for everyone to air an informed opinion, a related question is: > will loop fusion be allowed with function calls? > > Loop fusion currently only works with operators, and adding ^^ would allow: > > a[] = b[] ^^ 3; > > But with pow you can't do that: > > a[] = pow(b[], 3); > > > Andrei > > P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for > automatic loop fusion that would tilt my opinion in disfavor of ^^, and > if not, it would tilt my opinion in favor of ^^.
Does ^^ really even need to be a builtin operator to be overloadable? I remember a discussion where we considered adding abstract operators that have no inherent meaning in the language (not builtins), but are overloadable to allow better exploitation of infix notation. Things like (+), (*), (%), (&), [+], [*], [%], and so on.