People who hate fun, ignore this code, do not report as a bug

enum counter=cast(immutable(void)*)[0].ptr;
auto setcount(int i)=>(*(st(int*)counter))=i;
auto count()=>(*(cast(int*)counter));
auto apply(alias F)(){
	assert(__ctfe);
	enum _=setcount(F(count()));
	return true;
}
int G(int i){
	i+=3;
	i*=i;
	return i;
}
unittest{
	int i;
	i=G(i);
	enum _=apply!G;
	assert(i==count);
}

Does there exist a reasonable function G that causes this unittest to fail?

On Thursday, 29 May 2025 at 19:03:49 UTC, monkyyy wrote:

enum counter=cast(immutable(void)*)[0].ptr;
auto setcount(int i)=>(*(st(int*)counter))=i;

This is undefined behaviour. counter is typed as pointing to immutable data, but you're mutating it anyway in setcount which the compiler can assume you don't do. So there's no point in discussing what should make the unit test to pass or fail.

Yes, the one-element array is not originally typed as immutable, but it doesn't matter. immutable means that no-one will mutate the referenced data as long as the immutable reference exists, regardless of whether the data was read-only to begin with.

On Friday, 30 May 2025 at 10:08:54 UTC, Dukc wrote:

I currently believe nothing does and this is a highly flexible feature thats been in the compiler for years

On Friday, 30 May 2025 at 13:35:07 UTC, monkyyy wrote:

Doesn't matter. Whatever it does currently does isn't meant to be relied upon. It might change at any time.

Of course you can exploit what the compiler currently does but that's like using a kettle filled with boiling water as your clothes iron. Might work by accident, but neither the kettle nor your clothes are designed for that in mind and it's begging for trouble if you can just use a real clothes iron.

Or are you opining that this particular hack should be defined behaviour? If, what exactly should be guaranteed and why?

On Friday, 30 May 2025 at 14:12:20 UTC, Dukc wrote:

The rate of development is SLOW, and the change if there is one will be to just break this(out of spite of me having too much fun)

It doesn't matter what the spec says, what matters is how quickly and easily the feature works, this is higher on my list then delegates, because delegates are fundamentally broken and a #wontfix. If it starts out buggy, it will likely remain buggy even after years of whack a mole.

Features implemented by accident are among the best because they are pathologically simple if bad api

Ive asked for any and every compile time side effect. I think we should drop the pretense that templates are sane, stable and pure.