www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - tg counter robustness

reply monkyyy <crazymonkyyy gmail.com> writes:
People who hate fun, ignore this code, do not report as a bug


```d
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?
May 29
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 29 May 2025 at 19:03:49 UTC, monkyyy wrote:

 ```d
 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.
May 30
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 30 May 2025 at 10:08:54 UTC, Dukc wrote:

 So there's no point in discussing what should make the unit 
 test to pass or fail.


I currently believe nothing does and this is a highly flexible 
feature thats been in the compiler for years
May 30
parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 30 May 2025 at 13:35:07 UTC, monkyyy wrote:

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

 So there's no point in discussing what should make the unit 
 test to pass or fail.


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


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?
May 30
parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 30 May 2025 at 14:12:20 UTC, Dukc wrote:

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

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

 So there's no point in discussing what should make the unit 
 test to pass or fail.


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


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


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


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


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