constant fold typeid(T).tsize()

[WalterBright]

The idea here is that since the compiler knows what .tsize() is, it can be constant folded. Works with both runtime and compile time computations. If this is successful, will generalize it to more typeid members.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#11792"

[UplinkCoder]

@WalterBright how many lines is that? For just the size property?

[UplinkCoder]

messy stuff like that is exactly what I want to avoid. How about getting the UDA's on a type. do you also want that in typeid? vtbls? field-offsets?

[WalterBright]

For just the size property?

For the moment. I intend to expand it if successful to as many TypeInfo members as I can. This enables CTFE on typeid expressions. I should have thought of doing this optimization 10 years ago.

[UplinkCoder]

That is not generalized system though. type functions are.

[UplinkCoder]

@andralex What about looking at the big picture?

[ibuclaw]

Could tsize be adapted in such a way that allows constant folding, rather than the compiler shortcuting the call?

Genuine concern and possible use-case as there are a number of people/companies using D to target embedded systems.

If I implement the following in a "minimal" run-time library, either to discourage use or as a stub until it's implemented proper.

class TypeInfo
{
    @property final size_t tsize() nothrow pure const @safe @nogc { assert(false, "Unimplemented"); }
}

With this change, there's now a split brain between compiler and library.

[UplinkCoder]

@WalterBright when you remove the risky label please state why the PR is not risky anymore. The reason I added the risky label was because of Iains comment.

Genuine concern and possible use-case as there are a number of people/companies using D to target embedded systems.

If I implement the following in a "minimal" run-time library, either to discourage use or as a stub until it's implemented proper.

class TypeInfo
{
    @property final size_t tsize() nothrow pure const @safe @nogc { assert(false, "Unimplemented"); }
}

With this change, there's now a split brain between compiler and library.

Has this issue been addressed?

[RazvanN7]

@WalterBright what is your response to @ibuclaw's comments?

[RazvanN7]

@WalterBright What is the state of this PR and what is your response to @ibuclaw 's concerns?

[RazvanN7]

@WalterBright This is still failing the testsuite and also Iain's comment remains unaddressed.