std.typecons.RefCounted!(T, RefCountedAutoInitialize.no) should still work when T.this() is annotated with @disable

[n8sh]

No description provided.

[dlang-bot]

Thanks for your pull request, @n8sh!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21638	enhancement	std.typecons.RefCounted!(T, RefCountedAutoInitialize.no) should still work when T.this() is annotated with @disable

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 + phobos#7797"

[n8sh]

I'm not sure if making this a zero-args template is the cleanest solution for user-facing code. Would it be better to use a static if?

[RazvanN7]

Can you please provide some information on why templating the ensureInitialized method fixes this issue?

[n8sh]

@RazvanN7 templated code isn't compiled unless instantiated. ensureInitialized in turn instantiates initialize with zero arguments which fails to compile if T.this() is annotated with @disable. If the reason ensureInitialized is now a template isn't clear to someone who is very familiar with D programming that increases my doubt as to whether it's a good approach.

[RazvanN7]

What I meant is that you can still call ensureInitialized directly and that will result in a compilation error even if it is templated. The proper fix should make sure that ensureInitialized exists only when AutoInitialize = yes and error out ensureInitialized is used otherwise.

[n8sh]

There's no reason someone couldn't have been calling ensureInitialized manually with RefCountedAutoInitialize.no. It's a documented public method. So I would only remove it when it actually wouldn't compile.

Is there a better way to check for a @disable this() than !__traits(compiles, { static T t; } )?

[RazvanN7]

There's no reason someone couldn't have been calling ensureInitialized manually with RefCountedAutoInitialize.no

Right.

So I would only remove it when it actually wouldn't compile.

Actually, now that you mention, ideally, the method would always be present but it would assert when used
with a struct that has a disabled default constructor.

Is there a better way to check for a @disable this() than !__traits(compiles, { static T t; } )?

Not that I can think of.

[n8sh]

Actually, now that you mention, ideally, the method would always be present but it would assert when used
with a struct that has a disabled default constructor.

You mean at runtime rather than compile time?

[RazvanN7]

You mean at runtime rather than compile time?

Yes

[n8sh]

That would make sense if ensureInitialized is being conceptualized as an extra-helpful enforceInitialized. "The RefCounted should have already been initialized, so if by some oversight it hasn't been we will try to fix the situation if we know how."

But ensureInitialized isn't necessarily a fallback. It can be intentionally used as the path by which a RefCounted is initialized. In such cases it would be a huge step backwards to let the code compile but crash when executed.

[RazvanN7]

You have a point. However, the compilation error needs to be more targeted. IMHO it's a problem if you call ensure initialized but you get some error in the innards of std.conv. Basically, we need to spell out to the user that it's not possible to use ensureInitialized if T has disabled default construction.

[n8sh]

Added a static assert with an informative error message.