Re: confold

It’s slightly more complicated than that and my original (now removed) pull doesn’t solve it after then testing further, I need a flag. A flag so that I can identify from a call checker that it’s a literal const and optimize based upon that. 

What led me to this is the difference in performance I get between:

slot::get(“thing”);

And:

my $slot = “thing”;

slot::get($slot);

I’m slowly learning but my understanding is that in the first example I have an OP_CONST, so when I write a call checker in XS I can optimise based upon that

	op->op_type == OP_CONST

In the second example I am a OP_PADSV, I am not able to optimise this at compile time because I might not know its value. The confold is an idea to solve. 

I don’t think people would want this behaviour by default but it can be useful knowing at compile and not by small margins. I then start to think about actually making that readonly… because people tend to like const my $thing => ‘okays’ over use constants;

Regards,

Robert.


> On 30 Jan 2026, at 20:41, Josh Juran <[email protected]> wrote:
> 
> On Jan 30, 2026, at 3:38 PM, lnation <[email protected]> wrote:
> 
>> I’ve just made my first merge request into core, I would like to introduce a new operator <: (confold) - a prefix operator for compile-time constants.
>> 
>> The Problem:
>> 
>> Even literal string have runtime overhead.
>> 
>>   my $name = “string value”; # StIl executes ops at runtime
>> 
>> The Solution:
>> 
>> Add an operator so I can ensure folding at compile time. 
>> 
>>  my $name = <: “string value”; # Folded away - zero runtime ops.
> 
> Once the compile-time constant folding has been implemented, why not just have it always on instead of having to opt in?
> 
> Cheers,
> Josh
>