Adding Support for Custom Literal Constants

This sounds nice. I would also recommend instead of only supporting suffix, also support prefix. This is a bit more common in other programming languages when it comes to interpolated strings. For example, in C# you could do: $"val = {val}".

I don't really have any suggestion on this. I never started looking into this. I'm travelling for the next few weeks, so I won't be able to look into it this moment.

But I feel you're on the right path. To Miss' suggestion I think you could add to the function name something like _suffix or _prefix to tell the compiler which option to use.

Your approach is correct. For flexibility, expose utility functions for parsing raw literals (e.g., int∈ as const char*). Support numeric (uint64, double) and string-based (const string∈) literals for varied use cases.

Here’s a more detailed example of how your solution might look with the f32 suffix:

// registering behavior for f32 suffix
engine->RegisterObjectBehaviour("Fixed32", asBEHAVE_LITERAL_CONSTRUCT, "void f32(double)", asFUNCTION(Fixed32Constructor), asCALL_CDECL);

// example script usage
Fixed32 fixedValue = 3.14f32;

For the fmt literal:

// registering fmt behavior
engine->RegisterObjectBehaviour("string", asBEHAVE_LITERAL_CONSTRUCT, "void fmt(const string∈)", asFUNCTION(FormatConstructor), asCALL_CDECL);

// example script usage
int val = 42;
string str = "hello";
string result = "val = {val}, str = {str}"fmt;

The FormatConstructor would parse the string, replace placeholders with variable values, and return the resulting string.

Maybe we can have asBEHAVE_LITERAL_CONSTRUCT/FACTORY_PREFIX/SUFFIX for both user-defined prefix / suffix literals. But the user-defined prefix should only accept string, because f123 has ambiguity with an identifier.

In addition, maybe it also needs something like template callback to validate the user-defined literal? For example, if you have a suffix for fixed point number registered as void f32(int∈, uint) with a custom parser, you may want to only accept 3.14f32, while rejecting "str"f32 at compile-time. So, I think maybe there should be new behaviors called asBEHAVE_LITERAL_CALLBACK_PREFIX/SUFFIX too. The parameters are similar to the user-defined literals, but instead returning a Boolean value for validation.

I think it might be more elegant to do a solution similar to asBEHAVE_LIST_FACTORY https://angelcode.com/angelscript/sdk/docs/manual/doc_reg_basicref.html#doc_reg_basicref_4

Example “void f(double) {'f32' suffix}”

This will make it easier to support symbols such as $ that are normally not part of identifiers.

Yes, support for a callback is necessary as well to catch errors at compile time.

Finally I have sometime to continue this. I think the approach similar to declaring a list factory would be a better plan.

Another problem will be how to deal with conflicting literal names. For example, if a user register a void f(double) {'f' suffix}, it may conflict with the built-in suffix for a float literal.

Thank you so much for the help.

I've done the parsing function declaration part. Registering a user-defined literal will look like this

@witchlord But I have difficulty in finding where to modify the compiler. It seems that the asCCompiler::CompileExpressionValue is responsible for compiling constants. Is it correct to add code for calling user defined literal constructor/factory here?

Yes, that would be the correct spot. It should be done similar to how the string constants are done.

keeping this thread alive 🙂

@WitchLord

WitchLord said:

keeping this thread alive 🙂

I'm quite busy recently, because I'm about to graduate from the university. There are so many things to do. I'll come back to continue on this thread 2 ~ 3 weeks later.

No worries. Take you time. I just bumped up the thread because GameDev.net locks the threads after a few weeks of no activities.

Hey Henry,

I'm interested in helping on this feature as I currently also require something similar. I end up constructing constants of a particular primitive type every frame for things like time, and having them compiled as constants like strings would eliminate the issue. How far have you gotten in the AS side of things? Would you be willing to share the patch so far and I can try to pick up what's remaining to be implemented?

Paril said:

Hey Henry,

I'm interested in helping on this feature as I currently also require something similar. I end up constructing constants of a particular primitive type every frame for things like time, and having them compiled as constants like strings would eliminate the issue. How far have you gotten in the AS side of things? Would you be willing to share the patch so far and I can try to pick up what's remaining to be implemented?

I finally have some time. Previously, I used svn to clone the AngelScript library, and then send diff files via email. But I'm not familiar with svn, so I consider to put the existing code in a git branch (forked from the mirror library on GitHub). I will update the link in this thread when it is done.

Yeah that works. I can help test when it's ready. Thanks!

I had a thought about this: I wonder if instead of starting with the actual literal operator, this feature should start as a generic “pure” modifier which can be added to host functions. For example:

float sin(float) pure

This would mark the function pure; not modifying any globals, always providing the same output for the same inputs, etc. A pure function could, at compile time, be inlined into a constant if the function is called with inputs that are either constants or literals.

This would happen from the inside-out (not sure what the term is in AST-esque terms but what I mean is if you have nested function calls, it would evaluate pure function calls on the deepest levels first, so that it can properly constant-ize coming back out). For instance:

const float pi; // provided by host, not set in this example
float x = sin(pi); // at compile time, this function call can safely be inlined as `float x = 0`
float y = sin(0); // same as above
float z = sin(sin(1)); // this would inline the inner sin first, and then the outer sin, so it would become `float z = 0.7456...;`

Then, this feature can easily be used to handle the literal feature since those are just pure function calls written a different way (eg, gtime_t t = time_ms(0) is identical to gtime_t t = 0_ms because 0_ms is just rewritten at compile time into time_ms(0), which is then inlined).

The only thing that I have a hard time with is how this could apply to constructors. Like, reference types not being allowed to be pure at all is probably OK, although I guess in practice it could be done by calling the factory during compilation, calling the pure function, then destroying the object. Custom value types, though, would need some way of having pure constructors which can be used to pass them (either by value or by ref) to pure functions. eg:

vec3(float, float, float) pure

which allows this simple constructor to be passed to something theoretical like:

float sum(vec3 v) pure or float sum(const vec3 ∈ v) pure

as:

float x = sum(vec3(1, 2, 3))

or:

const vec3 t(1, 2, 3);
float x = sum(t);

pure functions is definitely an interesting feature that may be incorporated, it is no my to-do list already. But it is a different feature from the custom literals. Yes, the two might be combined, but there is no need to implement pure functions in order to provide the support for custom literals.

Reopening this thread since there is some movement on the development again.

I have some difficulties implementing the script parsing part. Taking the string constant as an example, I'm modifying the asCParser::ParseStringConstant for parsing script literal like "hello"_suffix , but it seems that support prefix literal is not feasible in this way. Maybe should we just support suffix literal at first?