www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interpolation struct names and location

reply Steven Schveighoffer <schveiguy gmail.com> writes:
[DIP 1036e](https://github.com/dlang/dmd/pull/15715) has been 
merged and is going to be in the next release (set to be cut on 
March 1).

Once this is upon the world, it will be very difficult to change 
the names of the types used for these things. I want to make sure 
everyone has a chance to think about this and suggest what they 
think.

The way the lowering is set up, you do NOT have to import 
`core.interpolation` to *use* them. Most of the time, you will be 
only doing that in order accept the types as function parametrers.

However, [these 
names](https://github.com/dlang/dmd/blob/98443676dcfa32f7234ebab6ca9f925e1d3cd736/druntime/src/core/i
terpolation.d#L102) are rather verbose. And every function that accepts these
sequences is going to be mangled with some pretty long names.

I propose we discuss both for where these types should live and 
what they should be called. I personally think we might want to 
move these things to object.d (yes, I know object.d is big, but 
these are not big or complex types), and rename them something 
more succinct.

Something like `iHeader`, `iFooter`, `iExpr`, `iLiteral` would be 
descriptive enough (everyone is going to be calling these 
istrings, even though they are Interpolation Expression 
Sequences).

This is the time to debate, before it's released!

-Steve
Feb 13
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
One option to consider is to give it a long name that is an alias in 
object.d but a short name in a second module.

That'll keep mangling to be a non-issue and attempt to keep object.d 
size down, even if it does mean an import.
Feb 13
parent reply Daniel N <no public.email> writes:
On Wednesday, 14 February 2024 at 05:33:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 One option to consider is to give it a long name that is an 
 alias in object.d but a short name in a second module.

 That'll keep mangling to be a non-issue and attempt to keep 
 object.d size down, even if it does mean an import.


importing another file, just slows down compilation.
Feb 14
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/02/2024 10:41 PM, Daniel N wrote:

 On Wednesday, 14 February 2024 at 05:33:54 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 One option to consider is to give it a long name that is an alias in 
 object.d but a short name in a second module.

 That'll keep mangling to be a non-issue and attempt to keep object.d 
 size down, even if it does mean an import.


 
 importing another file, just slows down compilation.


Not necessarily.

It all depends upon how lazy the compiler can be for: ``public import 
std.stdio : wln = writeln;``
Feb 14
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 14 February 2024 at 05:30:47 UTC, Steven 
Schveighoffer wrote:

 However, [these 
 names](https://github.com/dlang/dmd/blob/98443676dcfa32f7234ebab6ca9f925e1d3cd736/druntime/src/core/i
terpolation.d#L102) are rather verbose. And every function that accepts these
sequences is going to be mangled with some pretty long names.

 I propose we discuss both for where these types should live and 
 what they should be called. I personally think we might want to 
 move these things to object.d (yes, I know object.d is big, but 
 these are not big or complex types), and rename them something 
 more succinct.


I think putting them in `core.interpolation` instead of 
`object.d` is fine. Having to `import core.interpolation` when 
you write a function that takes an interpolation sequence is no 
worse than having to `import core.vararg` when you write a 
variadic function.

Normally, my suggestion would be to not repeat the module name in 
the type name, and just call these `core.interpolation.Header`, 
`core.interpolation.Footer`, `core.interpolation.Literal`, and 
`core.interpolation.Expression`. However, the names of these 
types are going to show up in user-facing error messages without 
the module name attached, so having some kind of prefix to 
distinguish them makes sense.

I agree that `Interpolation` is too long. `i` looks kind of weird 
to me (violates the D style rules about capitalization), but if 
we want brevity above all else, it's a reasonable choice. The 
only other thing I can think of is `Interp`
Feb 14
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 14 February 2024 at 12:59:34 UTC, Paul Backus wrote:

 I think putting them in `core.interpolation` instead of 
 `object.d` is fine. Having to `import core.interpolation` when 
 you write a function that takes an interpolation sequence is no 
 worse than having to `import core.vararg` when you write a 
 variadic function.


I'm not too worried about having to import. It's more of the fact 
that these are going to be mangled with the package/module name 
(though the mangling backreference system will limit this a bit).

I should probably actually test and see what it looks like.


 I agree that `Interpolation` is too long. `i` looks kind of 
 weird to me (violates the D style rules about capitalization), 
 but if we want brevity above all else, it's a reasonable 
 choice. The only other thing I can think of is `Interp`


I thought of `IHeader` but that looks like an interface...

I also thought of `IESHeader` but this is less obvious to someone 
who sees it.

InterpHeader is still long, but a bit better. Any reduction is 
better than no reduction?

-Steve
Feb 14
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 14 February 2024 at 16:28:32 UTC, Steven 
Schveighoffer wrote:

 I thought of `IHeader` but that looks like an interface...

 I also thought of `IESHeader` but this is less obvious to 
 someone who sees it.

 InterpHeader is still long, but a bit better. Any reduction is 
 better than no reduction?


`IstrHeader` or `IseqHeader`, maybe? Shaves off a couple more 
characters.
Feb 14
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 14 February 2024 at 12:59:34 UTC, Paul Backus wrote:

 On Wednesday, 14 February 2024 at 05:30:47 UTC, Steven 
 Schveighoffer wrote:

 [...]


 I think putting them in `core.interpolation` instead of 
 `object.d` is fine. Having to `import core.interpolation` when 
 you write a function that takes an interpolation sequence is no 
 worse than having to `import core.vararg` when you write a 
 variadic function.

 Normally, my suggestion would be to not repeat the module name 
 in the type name, and just call these 
 `core.interpolation.Header`, `core.interpolation.Footer`, 
 `core.interpolation.Literal`, and 
 `core.interpolation.Expression`. However, the names of these 
 types are going to show up in user-facing error messages 
 without the module name attached, so having some kind of prefix 
 to distinguish them makes sense.


This can be fixed by using the fully qualified name.
Feb 15
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 14 February 2024 at 05:30:47 UTC, Steven 
Schveighoffer wrote:

 This is the time to debate, before it's released!

 -Steve


One idea. For consistency with [named character 
entities](https://dlang.org/spec/entity.html) maybe it'd be 
better if these were escape sequences too? \$identifier or 
\$(an.expression), with "i" omitted from the beginning.

Don't hesistate to stratch this idea though if you're even 
slightly against it. Since Walter already approved the present 
syntax I don't think we should spend time debating the syntax 
further.
Feb 15
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 14 February 2024 at 05:30:47 UTC, Steven 
Schveighoffer wrote:

 […]

 However, [these 
 names](https://github.com/dlang/dmd/blob/98443676dcfa32f7234ebab6ca9f925e1d3cd736/druntime/src/core/i
terpolation.d#L102) are rather verbose. And every function that accepts these
sequences is going to be mangled with some pretty long names.

 […]


If mangled name length is an issue, couldn’t you name them 
something very, very succinct like `__iH`, `__iF`, `__iE`, and 
`__iL` and just define some easy-to-comprehend aliases? As far as 
short mangling is concerned, the succinct identifiers need not 
even be (public) in object.d, only the aliases.
Feb 15