## digitalmars.D - Uniform Function Call Syntax?

• user001 (22/22) Mar 03 2016 Was just wondering why UFCS only works in one direction, that is
• Era Scarecrow (13/19) Mar 03 2016 Immediately looking at only that part of the code, i have to ask
• user001 (14/35) Mar 03 2016 You can say the same thing about how it is currently implemented.
• Walter Bright (3/7) Mar 05 2016 If that's how you want to call dot, add the following:
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (12/14) Mar 05 2016 Why don't you just define it as "dot(a,b)" to begin with?
user001 <youdontneedthis dont.com> writes:
```Was just wondering why UFCS only works in one direction, that is
why functions can be used as if it were part of a struct/class
but not the other way around.

struct Vec3
{
float x;
float y;
float z;

float dot(Vec3 o)
{
return x * o.x + y * o.y + z * o.z;
}
}

int dot;
Vec3 a, b;

float value = dot(a, b); // would be same as a.dot(b)
// doesn't try to use local "int dot"

It may not add as much value but I think it'd be a bit better as
now you no longer have a global function with a simple name
"dot". For mathematical purposes it is a lot easier to understand
"dot(a, b)" than "a.dot(b)", at least in my opinion. Just curious
that's all.
```
Mar 03 2016
Era Scarecrow <rtcvb32 yahoo.com> writes:
```On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
Was just wondering why UFCS only works in one direction, that
is why functions can be used as if it were part of a
struct/class but not the other way around.

int dot;

float value = dot(a, b); // would be same as a.dot(b)
// doesn't try to use local "int dot"

Immediately looking at only that part of the code, i have to ask
'how the hell are you calling the int???'. Of course i can tell
from your source dot is also a function in the vector.

Considering dot could now shadow the variables or function
names, it would quickly QUICKLY become annoying. A hierarchy of
how the call is used plus the documentation of what it's
obviously doing is a much better approach. Not to mention we've
been using . and -> and * so long for accessing/de-referencing
members that are attached so long that changing it is probably
not an option. MAYBE if you were starting a language from
scratch, but in this case i would firmly say no, this is ugly and
confusing.
```
Mar 03 2016
user001 <youdontneedthis dont.com> writes:
```On Friday, 4 March 2016 at 02:09:25 UTC, Era Scarecrow wrote:
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
Was just wondering why UFCS only works in one direction, that
is why functions can be used as if it were part of a
struct/class but not the other way around.

int dot;

float value = dot(a, b); // would be same as a.dot(b)
// doesn't try to use local "int dot"

Immediately looking at only that part of the code, i have to
ask 'how the hell are you calling the int???'. Of course i can
tell from your source dot is also a function in the vector.

Considering dot could now shadow the variables or function
names, it would quickly QUICKLY become annoying. A hierarchy of
how the call is used plus the documentation of what it's
obviously doing is a much better approach. Not to mention we've
been using . and -> and * so long for accessing/de-referencing
members that are attached so long that changing it is probably
not an option.

You can say the same thing about how it is currently implemented.

int[] arr = [ 0, 1, 2, 3 ];

static map(alias F)(int[])
{
}

writeln(arr.map!(a => a * 2)); // what does this mean array
doesnt have a map function, does it use the local map function or
the global one?

MAYBE if you were starting a language from scratch, but in this
case i would firmly say no, this is ugly and confusing.

Well it could possibly be happening with C++17 so it's not that
big of stretch to add it to an existing language, especially if
that language already has it half implemented.
```
Mar 03 2016
Walter Bright <newshound2 digitalmars.com> writes:
```On 3/3/2016 5:56 PM, user001 wrote:
It may not add as much value but I think it'd be a bit better as now you no
longer have a global function with a simple name "dot". For mathematical
purposes it is a lot easier to understand "dot(a, b)" than "a.dot(b)", at least
in my opinion. Just curious that's all.

If that's how you want to call dot, add the following:

float dot(Vec3 a, Vec3 b) { return a.dot(b); }
```
Mar 05 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
"dot". For mathematical purposes it is a lot easier to
understand "dot(a, b)" than "a.dot(b)", at least in my opinion.

Why don't you just define it as "dot(a,b)" to begin with?

I think it would be better idea to just add the ability to add
unicode operators, and to avoid precedence issues one could just
require them to use parentheses. That way you could define
opCustom"•" and use it as:

( point1 • point2 )

An often stated golden rule in language design is that there
should be one way to do something. When you break that rule it
often is due to a language design deficiency. UFCS in both D and
C++ are hacks. IMO that makes things more confusing, not more
clear.
```
Mar 05 2016
Xinok <xinok live.com> writes:
```On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad
wrote:
I think it would be better idea to just add the ability to add
unicode operators, and to avoid precedence issues one could
just require them to use parentheses. That way you could define
opCustom"•" and use it as:

( point1 • point2 )

Please no. If I need to open up Character Map just to write code,
something has gone horribly wrong.
```
Mar 06 2016
Patience <Patience.Is Virtue.Life> writes:
```On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad
wrote:
I think it would be better idea to just add the ability to add
unicode operators, and to avoid precedence issues one could
just require them to use parentheses. That way you could
define opCustom"•" and use it as:

( point1 • point2 )

Please no. If I need to open up Character Map just to write
code, something has gone horribly wrong.

A proper code editor could handle this. Type something like ctrl
+ ? and it pops up all the implemented uni-code operators.

Else we are stuck in the past until you decide to change...
```
Mar 06 2016
Era Scarecrow <rtcvb32 yahoo.com> writes:
```On Monday, 7 March 2016 at 06:02:46 UTC, Patience wrote:
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write
code, something has gone horribly wrong.

A proper code editor could handle this. Type something like
ctrl + ? and it pops up all the implemented uni-code operators.

Else we are stuck in the past until you decide to change...

I'm reminded. Weren't there standard 50-something keyboards, and
then 101 keyboards? And you actually COULDN'T do programming on
the 50-key keyboards because literally standard symbols were
missing?

Honestly it would be annoying to have to pull up character map,
memorize ascii or unicode characters, or even require a helper
program which isn't present on most tools.

I have an excellent idea! I'll start programming using nothing
but the greek alphabet, better yet unicode characters!

//謎機能
int æ(File ß, int Ɣ, int Ʊ) {
return Ɣ 乘 Ɣ 加 Ʊ 子 7;
}

Actually let's alias off the ints too because, we don't need
those.

//謎機能
數 æ(數 Ɣ, 數 Ʊ) {
return Ɣ 乘 Ɣ 加 Ʊ 子 7;
}

i happy i cut & paste everywhere (instead of relying on
standardized ascii characters that actually mean something to
me... Okay maybe this went off track)
```
Mar 06 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 06:48:10 UTC, Era Scarecrow wrote:
I'm reminded. Weren't there standard 50-something keyboards,
and then 101 keyboards? And you actually COULDN'T do
programming on the 50-key keyboards because literally standard
symbols were missing?

No unicode. No keys. No mouse. No bitmap graphics. Just a
hardwired terminal. Welcome to the 60s and 70s.

I have an excellent idea! I'll start programming using nothing
but the greek alphabet, better yet unicode characters!

immutable π = 3.14;

writeln( ∑(values) );

x = x + ∆;

Oh, the horror!
```
Mar 06 2016
Era Scarecrow <rtcvb32 yahoo.com> writes:
```On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad
wrote:
immutable π = 3.14;

Oh, the horror!

With the assumption pi is declared elsewhere (say, in std.math),
what i wonder is the number for pi vs 2 letters. Unicode 03C0h,
so now i have to convert that to decimal, code 960. Alt+960 = └

That's not pi... Looking up the symbol by itself in the
character map was annoying enough. No, this is not a good idea
unless it's easily accessible, preferably with 2 or fewer
keystrokes to symbolize pi.

As a reminder most of us are programmers, not scientists or
mathematicians. Having specialized symbols won't give us any
benefit. It's not like we're filling out a complex formula with
college level math for a thesis.
```
Mar 06 2016
krzaq <dlangmailinglist krzaq.cc> writes:
```On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad
wrote:
immutable π = 3.14;

Oh, the horror!

With the assumption pi is declared elsewhere (say, in
std.math), what i wonder is the number for pi vs 2 letters.
Unicode 03C0h, so now i have to convert that to decimal, code
960. Alt+960 = └

That's not pi... Looking up the symbol by itself in the
character map was annoying enough. No, this is not a good idea
unless it's easily accessible, preferably with 2 or fewer
keystrokes to symbolize pi.

As a reminder most of us are programmers, not scientists or
mathematicians. Having specialized symbols won't give us any
benefit. It's not like we're filling out a complex formula with
college level math for a thesis.

Honestly, any tool can be abused. Javascript, Swift and even
partially Haskell allow unicode names and I'm sure we all saw
that toy example that was full of emojis, but can you say it has
been a problem in practice?
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad
wrote:
immutable π = 3.14;

Oh, the horror!

With the assumption pi is declared elsewhere (say, in
std.math), what i wonder is the number for pi vs 2 letters.
Unicode 03C0h, so now i have to convert that to decimal, code
960. Alt+960 = └

That's not pi... Looking up the symbol by itself in the
character map was annoying enough. No, this is not a good idea
unless it's easily accessible, preferably with 2 or fewer
keystrokes to symbolize pi.

But you can already use "π" in D code? D is inconsistent in what
parts of unicode you can use in names though. I don't think you
can use "∂"...

As a reminder most of us are programmers, not scientists or
mathematicians. Having specialized symbols won't give us any
benefit. It's not like we're filling out a complex formula with
college level math for a thesis.

operators is just a small extension. And you don't have to use it
if you don't want to.

There is no standard english notation for the inner product
either, "dot" refers to the sigil... But if you want both, you
can have both. You can both have "innerProduct(v1,v2)" and "(v1 •
v2)".

In a commercial setting you want as high level of legibility as
possible. D is doing slightly better than C++, but is far away
from providing a good legible syntax. More time is spent reading
code than writing it.

In some cases people want to use their own language. D supports
that. Math notation is no different than using a non-english
language in that regard. Why shouldn't mathematicians be allowed
to user the language they are familiar with if national languages
are supported?
```
Mar 07 2016
Chris Wright <dhasenan gmail.com> writes:
```On Mon, 07 Mar 2016 10:32:09 +0000, Ola Fosheim Grøstad wrote:
D is inconsistent in what parts
of unicode you can use in names though.

The basic idea is that you can use any letter or '_' as the first element
of an identifier, and you can use any letter or number or '_' as a
subsequent element of an identifier. That's simple and consistent, right?

Except it's based on C99's fixed list of characters. So the actual rule
is, you can use symbols from about 25 different writing systems that the
designers of C99 thought prevalent enough to include, so long as they
were in Unicode before 1999.

C#, in contrast, uses Unicode categories. You can use the Cherokee
alphabet in C# identifiers, and there are under 400,000 speakers of
Cherokee. Making that work took far less effort for the C# standard
authors than the choice of identifier characters for C99.

I'm relatively certain that Walter went with C99's rules in large part
available library with an appropriate license to give the Unicode
category for a given codepoint.

But you can already use "π" in D code?

U+03C0 (π) is from the Greek alphabet section of the Unicode inventory.
It's for writing in the Greek language, which is currently spoken by
about thirteen million people. It is primarily a letter, with incidental
usage as a mathematical symbol.

Therefore, based on the rule that you can always start an identifier with
a letter, you can use π as an identifier.

I don't think you can use "∂"...

The partial integral symbol is not a letter or digit under any
circumstances. It is a mathematical symbol. Identifiers cannot contain
mathematical symbols in D or C99 or even C#.
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
The partial integral symbol is not a letter or digit under any
circumstances. It is a mathematical symbol. Identifiers cannot
contain mathematical symbols in D or C99 or even C#.

Well, but that argument is kinda bogus. Scientists have
"invented" their own notation using whatever symbols (characters)
just because language designers are reactionary. :-)

There are lots of interesting letters from various languages that
can be used, so prohibiting access to the proper symbols is kinda
pointless. The end result is that people just pick inappropriate
```
Mar 07 2016
Chris Wright <dhasenan gmail.com> writes:
```On Mon, 07 Mar 2016 18:45:34 +0000, Ola Fosheim Grøstad wrote:

On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
The partial integral symbol is not a letter or digit under any
circumstances. It is a mathematical symbol. Identifiers cannot contain
mathematical symbols in D or C99 or even C#.

Well, but that argument is kinda bogus. Scientists have "invented" their
own notation using whatever symbols (characters)
because language designers are reactionary. :-)

It's still not inconsistent to disallow math symbols. There's a simple
rule that the C99 standards writers were attempting to approximate, and
that simple rule excludes mathematical symbols.

You dislike and disagree with that decision, which is a separate
complaint. I'm sympathetic to the language designers here: I want to
guide people toward using descriptive names, because that makes it easier
to read code, which makes it easier to verify correctness. Math notation
tends to be very compact and inscrutable, and I don't want to encourage
users of my language to use inscrutable identifiers.
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 18:57:03 UTC, Chris Wright wrote:
It's still not inconsistent to disallow math symbols.

It is inconsistent if you accept that different communities have
different notations/languages. Why you would you want to exclude
the scientific community?

here: I want to guide people toward using descriptive names,
because that makes it easier to read code, which makes it
easier to verify correctness.

Err, no, the contrary. What you get is an incomprehensible and
overly verbose mess that hide problems and/or result in excessive
problems, it gets messy quickly.

People don't write descriptive names, they write short names, if
you provide a very limited set of symbols. Like "dot".
```
Mar 07 2016
Chris Wright <dhasenan gmail.com> writes:
```On Mon, 07 Mar 2016 18:45:34 +0000, Ola Fosheim Grøstad wrote:
There are lots of interesting letters from various languages that can be
The end result is that people just pick inappropriate characters

I don't think history bears that out. I've never seen this happen in
Java, C#, or Python.
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote:
I don't think history bears that out. I've never seen this
happen in Java, C#, or Python.

You haven't seen people do it in D?
```
Mar 08 2016
Chris Wright <dhasenan gmail.com> writes:
```On Tue, 08 Mar 2016 18:59:47 +0000, Ola Fosheim Grøstad wrote:

On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote:
I don't think history bears that out. I've never seen this happen in
Java, C#, or Python.

You haven't seen people do it in D?

No.
```
Mar 08 2016
Lass Safin <lasssafin gmail.com> writes:
```On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad
wrote:
immutable π = 3.14;

Oh, the horror!

With the assumption pi is declared elsewhere (say, in
std.math), what i wonder is the number for pi vs 2 letters.
Unicode 03C0h, so now i have to convert that to decimal, code
960. Alt+960 = └

That's not pi... Looking up the symbol by itself in the
character map was annoying enough. No, this is not a good idea
unless it's easily accessible, preferably with 2 or fewer
keystrokes to symbolize pi.

As a reminder most of us are programmers, not scientists or
mathematicians. Having specialized symbols won't give us any
benefit. It's not like we're filling out a complex formula with
college level math for a thesis.

Have you ever heard of .XCompose?
For linux: https://github.com/kragen/xcompose
For windows: https://github.com/samhocevar/wincompose
How it works:
You choose a compose key, then use it to compose special
characters with specific sequences.

Examples:
ComposeKey, *, p: π.
ComposeKey, s, s: ß
ComposeKey, ComposeKey, d, e, g, c (degree Celsius): ℃

It is not impossible to use unicode special characters on a daily
base easily, with the use of this tool. No need to use the
character map or anything.
I think it would be very nice, if one had the option of using
these special characters.
E.g. → instead of >>, if you desire that; std.math defining π as
π.
Small gimmicks like these are things I find to be good for a
language to have.
```
Mar 07 2016
Chris Wright <dhasenan gmail.com> writes:
```On Mon, 07 Mar 2016 12:58:51 +0000, Lass Safin wrote:
Have you ever heard of .XCompose?
For linux: https://github.com/kragen/xcompose For windows:
https://github.com/samhocevar/wincompose How it works:
You choose a compose key, then use it to compose special characters with
specific sequences.

Alternatively, you can create a custom keyboard layout for Linux
relatively easily. The text format is relatively legible, but to
simplify, you can use a utility such as
https://github.com/simos/keyboardlayouteditor .

For instance, I find myself using the characters ðþƹāē often for personal
reasons, plus åøæ when I was learning Norwegian, so I created a keyboard
layout to simplify that.

Still doesn't make it a great idea, but if your code's audience is
sufficiently constrained, you might find it makes some things more usable.
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write
code, something has gone horribly wrong.

Modern languages support Unicode in names, so it is too late:

import std.stdio;

void main()
{
writeln(Ø(3));
}
```
Mar 06 2016
Timon Gehr <timon.gehr gmx.ch> writes:
```On 07.03.2016 01:19, Xinok wrote:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote:
I think it would be better idea to just add the ability to add unicode
operators, and to avoid precedence issues one could just require them
to use parentheses. That way you could define opCustom"•" and use it as:

( point1 • point2 )

Please no. If I need to open up Character Map just to write code,
something has gone horribly wrong.

That "something" is your editor configuration. Seriously, this is a
trivial problem.
```
Mar 07 2016
Wyatt <wyatt.epp gmail.com> writes:
```On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad
wrote:
I think it would be better idea to just add the ability to add
unicode operators, and to avoid precedence issues one could
just require them to use parentheses. That way you could define
opCustom"•" and use it as:

I've mentioned this before, but I think a constrained set of
user-defined operators using annotations/affixes on the existing
set is a better fit for D.  It's a lesson well-learned from other
languages (cf. OCaml; F#), and fits with D's generally practical
bent.

I mean, if you want to alias them to Lucky Charms or various
hieroglyphs of birds disemboweling men later, I guess maybe
that's could work? But I really don't want any language features
predicated on the programmer having an APL keyboard.

-Wyatt
```
Mar 07 2016
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
```On Monday, 7 March 2016 at 17:49:35 UTC, Wyatt wrote:
I've mentioned this before, but I think a constrained set of
user-defined operators using annotations/affixes on the
existing set is a better fit for D.  It's a lesson well-learned
from other languages (cf. OCaml; F#), and fits with D's
generally practical bent.

Not sure what you mean by annotations/affixes and what lesson
there is to be learned? What problems have other languages had
with this?

I mean, if you want to alias them to Lucky Charms or various
hieroglyphs of birds disemboweling men later, I guess maybe
that's could work? But I really don't want any language
features predicated on the programmer having an APL keyboard.

I don't see how mixfix notation makes this "problem" larger than
the current prefix notation.

Why is the current situation that allows "ø(x,y)" less
problematic than the proposed "(x ø y)" ?
```
Mar 07 2016
Timon Gehr <timon.gehr gmx.ch> writes:
```On 07.03.2016 18:49, Wyatt wrote:
But I really don't want any language features predicated on the
programmer having an APL keyboard.

I can't think of any language feature that would be.
```
Mar 07 2016