DIP 1036e 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 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

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.

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

On Wednesday, 14 February 2024 at 12:59:34 UTC, Paul Backus wrote:

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 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

On Wednesday, 14 February 2024 at 16:28:32 UTC, Steven Schveighoffer wrote:

IstrHeader or IseqHeader, maybe? Shaves off a couple more characters.

On Wednesday, 14 February 2024 at 12:59:34 UTC, Paul Backus wrote:

This can be fixed by using the fully qualified name.

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

One idea. For consistency with named character entities 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.

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

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.