<p>Lots of languages do not clearly separate the declaration of a variable, function or type from naming that entity, or if they do it does not have a uniform syntax. Consider C++:</p>
<ul>
<li>Naming a variable: <code>int foo = 42;</code> or <code>auto foo = int(42);</code></li>
<li>Naming a type: <code>class Bar { int x; };</code> or <code>using Bar = class { int x; };</code></li>
<li>Naming a function: <code>void baz() {};</code>, but <code>auto baz = [](){};</code> is <em>not</em> a function.</li>
</ul>
<p>I think it would be worthwhile to separate the naming from declaring the entities, so for example it should be possible to define an unnamed variable/type/function, and then name it using a uniform syntax. For example, using the <code>name: entity</code> notation:</p>
<ul>
<li><code>foo: int(42);</code></li>
<li><code>Bar: class { x: int; };</code></li>
<li><code>baz: (){};</code></li>
</ul>
<p>Omitting the <code>name:</code> part should then also be valid, and <code>name</code> and <code>entity</code> should be exchangeable. For example, currently in C++ you can write:</p>
<pre><code>struct Bar { int x; };
constexpr int y = 42;
template&lt;typename T = Bar, auto N = y&gt; class Quux {…};
</code></pre>
<p>But the following is illegal:</p>
<pre><code>template&lt;typename T = struct { int x; }, auto N = 42&gt; class Quux {…};
</code></pre>
<p>Because a <code>struct</code> declaration is not allowed in the template parameter list. Having a universal naming syntax would avoid these inconsistencies in the language.</p>
<p>I already see some issues with this: for example, the declaration <code>x: int</code> might be ambiguous; is this declaring a variable of type <code>int</code> (as in <code>int x;</code>), or is it declaring an alias for the type <code>int</code> (as in <code>using x = int;</code>)?</p>
<p>Are there any languages that already have such a way to name things, and what other problems would this have? Is there a better solution?</p>

<language-design><declarations>
What is a good universal naming syntax?
CC BY-SA 4.0
2023-07-04T22:00:43.440Z
Welcome! It's not clear why you think it's worthwhile to separate the name from the declaration; is there a specific problem that doing this would solve, or is it just an aesthetic issue?
kaya3
CC BY-SA 4.0
2023-07-04T22:47:00.147Z
@kaya3-supportthestrike It's not just aesthetics; the goal is to avoid inconsistencies in languages. I've amended the question, I hope that makes it a bit more clear?
G. Sliepen
CC BY-SA 4.0
2023-07-04T22:54:49.030Z
I see. But as far as I see, a language could very well support syntax like `template<typename T = struct { int x; }, auto N = 42> class Quux {…};` without needing a "universal naming syntax".
kaya3
<h1>Assignment syntax</h1>
<p>This is extra true for languages in which classes and functions <em>are</em> expressions (JavaScript technically counts, but some languages completely lack class/function <em>declarations</em>), although it's true that expressions and declarations aren't the same thing.</p>
<pre class="lang-js prettyprint-override"><code>const Foo = class {}
class {}

const bar = function () {}
function () {}
</code></pre>
<h1>OCaml syntax</h1>
<p>Note that module syntax is the only special one here.</p>
<pre class="lang-ocaml prettyprint-override"><code>let val = ()
()

type t = a * b
a * b

module Name : optional_signature = struct &lt;definition&gt; end
module struct &lt;definition&gt; end
</code></pre>
<h1>JavaScript syntax</h1>
<p>So, <code>&lt;type&gt; &lt;name&gt; &lt;definition&gt;</code>.<br />
It's not &quot;universal&quot; in the sense that it's the same syntactic construct, but it's &quot;universal&quot; in the sense that names are specified the same way for all constructs.</p>
<p>For variables it's not <em>quite</em> the same...</p>
<pre class="lang-javascript prettyprint-override"><code>var foo = 42
let foo = 42
const foo = 42
42

var fn = () =&gt; {}
() =&gt; {}
</code></pre>
<p>... but for classes and functions it's just a matter of omitting the name</p>
<pre class="lang-js prettyprint-override"><code>class Bar {}
class {}

function baz() {}
function () {}
</code></pre>

CC BY-SA 4.0
2023-07-05T00:09:23.287Z
2023-07-05T01:24:16.450Z
2023-07-05T01:24:16.450Z
somebody
CC BY-SA 4.0
2023-07-05T00:10:03.477Z
(if convention is to put all suggestions in a single answer please feel free to let me know)
somebody
CC BY-SA 4.0
2023-07-05T00:33:13.007Z
Welcome to PLDI! Normally, all suggestions in a single answer is better than spread out over multiple answers. You might also want to add some detail about what the code does/is, as it seems a bit unclear right now.
Redz
CC BY-SA 4.0
2023-07-05T01:29:01.423Z
fair enough, one answer per answer is just a habit i had... a bit weird though, bc if all suggestions in a single answer is the way to go then wouldn't a single CW answer for every question be the *most* conventional? or rather - what is the benefit of combining multiple suggestions together (but not all of them)?
somebody
# What is a good universal naming syntax?
Posted by: username_0 on 2023-07-04
Lots of languages do not clearly separate the declaration of a variable, function or type from naming that entity, or if they do it does not have a uniform syntax. Consider C++:

Naming a variable: int foo = 42; or auto foo = int(42);
Naming a type: class Bar { int x; }; or using Bar = class { int x; };
Naming a function: void baz() {};, but auto baz = [](){}; is not a function.

I think it would be worthwhile to separate the naming from declaring the entities, so for example it should be possible to define an unnamed variable/type/function, and then name it using a uniform syntax. For example, using the name: entity notation:

foo: int(42);
Bar: class { x: int; };
baz: (){};

Omitting the name: part should then also be valid, and name and entity should be exchangeable. For example, currently in C++ you can write:
struct Bar { int x; };
constexpr int y = 42;
template class Quux {…};

But the following is illegal:
template class Quux {…};

Because a struct declaration is not allowed in the template parameter list. Having a universal naming syntax would avoid these inconsistencies in the language.
I already see some issues with this: for example, the declaration x: int might be ambiguous; is this declaring a variable of type int (as in int x;), or is it declaring an alias for the type int (as in using x = int;)?
Are there any languages that already have such a way to name things, and what other problems would this have? Is there a better solution?
**Tags:** language-design declarations
> **Comments:**
> **username_1**: Welcome! It's not clear why you think it's worthwhile to separate the name from the declaration; is there a specific problem that doing this would solve, or is it just an aesthetic issue?  
> **username_0**: @kaya3-supportthestrike It's not just aesthetics; the goal is to avoid inconsistencies in languages. I've amended the question, I hope that makes it a bit more clear?  
> **username_1**: I see. But as far as I see, a language could very well support syntax like `template<typename T = struct { int x; }, auto N = 42> class Quux {…};` without needing a "universal naming syntax".  
---
## 1 answers
### Answer by username_2 on 2023-07-05. Score: 4
Assignment syntax
This is extra true for languages in which classes and functions are expressions (JavaScript technically counts, but some languages completely lack class/function declarations), although it's true that expressions and declarations aren't the same thing.
const Foo = class {}
class {}

const bar = function () {}
function () {}

OCaml syntax
Note that module syntax is the only special one here.
let val = ()
()

type t = a * b
a * b

module Name : optional_signature = struct  end
module struct  end

JavaScript syntax
So,   .
It's not "universal" in the sense that it's the same syntactic construct, but it's "universal" in the sense that names are specified the same way for all constructs.
For variables it's not quite the same...
var foo = 42
let foo = 42
const foo = 42
42

var fn = () => {}
() => {}

... but for classes and functions it's just a matter of omitting the name
class Bar {}
class {}

function baz() {}
function () {}
> **Comments:**
> **username_2** (2023-07-05): (if convention is to put all suggestions in a single answer please feel free to let me know)  
> **username_3** (2023-07-05): Welcome to PLDI! Normally, all suggestions in a single answer is better than spread out over multiple answers. You might also want to add some detail about what the code does/is, as it seems a bit unclear right now.  
> **username_2** (2023-07-05): fair enough, one answer per answer is just a habit i had... a bit weird though, bc if all suggestions in a single answer is the way to go then wouldn't a single CW answer for every question be the *most* conventional? or rather - what is the benefit of combining multiple suggestions together (but not all of them)?  
---
