Menu
Search

Forums

Forum Index

September 28, 2021
Gravatar of WebFreak001Posted by WebFreak001
in reply to Stefan Koch		Reply
WebFreak001
Gravatar of WebFreak001
Posted in reply to Stefan Koch


Reply

On Monday, 27 September 2021 at 15:17:39 UTC, Stefan Koch wrote:

>

On Monday, 27 September 2021 at 13:12:32 UTC, WebFreak001 wrote:

>

If it's mistyped, the compiler will complain that it doesn't exist

core.reflect will tell you that you tried to resolve a name which does not exist as well.

>

When it's an identifier, IDE refactorings (automated renaming) will find it, while it wouldn't find it in a string, especially the more generic the name is (which is common for template types T)

C# has nameof(T) which just returns "T" or for nameof(Foo.T) it also just returns "T"

That's valid.
I have to think about what to do about that.
Maybe remove the "" for the refactoring?
a simple search for nodeFromName\(\"$ID\"\) maybe?
It's the only primitive in code reflect which does this.

maybe for nodeFromName("T") leave it unsolved but there could also be a nodeFrom!T which could additionally check for the type of T and return the correct node type (like EnumDeclaration from enums)

This would additionally remove the need to do casts (and potentially mess up)

September 28, 2021
Gravatar of Adam D RuppePosted by Adam D Ruppe
in reply to bauss		Reply
Adam D Ruppe
Gravatar of Adam D Ruppe
Posted in reply to bauss


Reply
On Tuesday, 28 September 2021 at 06:43:39 UTC, bauss wrote:
> Yeah, I really wish we had an alternative to stringof like nameof. I often forgot that aliases don't work well with it, as displayed here :)

It is called

__traits(identifier)

.stringof should never be used outside of debugging messages.
September 28, 2021
Gravatar of Stefan KochPosted by Stefan Koch
in reply to WebFreak001		Reply
Stefan Koch
Gravatar of Stefan Koch
Posted in reply to WebFreak001


Reply

On Tuesday, 28 September 2021 at 07:10:43 UTC, WebFreak001 wrote:

>

maybe for nodeFromName("T") leave it unsolved but there could also be a nodeFrom!T which could additionally check for the type of T and return the correct node type (like EnumDeclaration from enums)

This would additionally remove the need to do casts (and potentially mess up)

I can provide a NodeFromAlias. But I don't want to promote such use.
I went through some of trouble to avoid static polymorphism.

I have to admit it is though it is tempting to chose the more convenient.
node!bla syntax.

September 28, 2021
Gravatar of Per NordlöwPosted by Per Nordlöw
in reply to Adam D Ruppe		Reply
Per Nordlöw
Gravatar of Per Nordlöw
Posted in reply to Adam D Ruppe


Reply

On Tuesday, 28 September 2021 at 11:45:37 UTC, Adam D Ruppe wrote:

>

It is called

__traits(identifier)

.stringof should never be used outside of debugging messages.

Why is .stringof worse than __traits(identifier)?

September 28, 2021
Gravatar of Alexandru ErmicioiPosted by Alexandru Ermicioi
in reply to Per Nordlöw		Reply
Alexandru Ermicioi
Gravatar of Alexandru Ermicioi
Posted in reply to Per Nordlöw


Reply

On Tuesday, 28 September 2021 at 12:32:04 UTC, Per Nordlöw wrote:

>

On Tuesday, 28 September 2021 at 11:45:37 UTC, Adam D Ruppe wrote:

>

It is called

__traits(identifier)

.stringof should never be used outside of debugging messages.

Why is .stringof worse than __traits(identifier)?

Because traits identifier is well defined to return only the id of the subject, while stringof can return more than id. It can for example return the expression as a string.

September 28, 2021
Gravatar of Per NordlöwPosted by Per Nordlöw
in reply to Per Nordlöw		Reply
Per Nordlöw
Gravatar of Per Nordlöw
Posted in reply to Per Nordlöw


Reply

On Tuesday, 28 September 2021 at 12:32:04 UTC, Per Nordlöw wrote:

> >

.stringof should never be used outside of debugging messages.

Why? And in what cases is.stringof worse than __traits(identifier)?

Note that .stringof works in cases where __traits(identifier) doesn't, such as in

alias S = string;
pragma(msg, S.stringof); // ok, print `string`
pragma(msg, __traits(identifier, S)); // fails

.

September 28, 2021
Gravatar of Adam D RuppePosted by Adam D Ruppe
in reply to Per Nordlöw		Reply
Adam D Ruppe
Gravatar of Adam D Ruppe
Posted in reply to Per Nordlöw


Reply
On Tuesday, 28 September 2021 at 12:38:52 UTC, Per Nordlöw wrote:
> Note that `.stringof` works in cases where `__traits(identifier)` doesn't, such as in

That's because a type has no identifier. And this is good anyway because there's never a good reason to get a type as a string. It is a bug waiting to happen any time someone writes that, so making it an error is a good thing.
September 28, 2021
Gravatar of Per NordlöwPosted by Per Nordlöw
in reply to Adam D Ruppe		Reply
Per Nordlöw
Gravatar of Per Nordlöw
Posted in reply to Adam D Ruppe


Reply

On Tuesday, 28 September 2021 at 12:48:08 UTC, Adam D Ruppe wrote:

>

That's because a type has no identifier. And this is good anyway because there's never a good reason to get a type as a string. It is a bug waiting to happen any time someone writes that, so making it an error is a good thing.

Can you elaborate on why you consider this being a bug?

September 28, 2021
Gravatar of Adam D RuppePosted by Adam D Ruppe
in reply to Per Nordlöw		Reply
Adam D Ruppe
Gravatar of Adam D Ruppe
Posted in reply to Per Nordlöw


Reply
On Tuesday, 28 September 2021 at 12:53:36 UTC, Per Nordlöw wrote:
> Can you elaborate on why you consider this being a bug?

https://forum.dlang.org/post/fbcltjuysmjrxmebeeva@forum.dlang.org

https://stackoverflow.com/questions/32615733/struct-composition-with-mixin-and-templates/32621854#32621854
September 28, 2021
Gravatar of baussPosted by bauss
in reply to Adam D Ruppe		Reply
bauss
Gravatar of bauss
Posted in reply to Adam D Ruppe


Reply
On Tuesday, 28 September 2021 at 11:45:37 UTC, Adam D Ruppe wrote:
> On Tuesday, 28 September 2021 at 06:43:39 UTC, bauss wrote:
>> Yeah, I really wish we had an alternative to stringof like nameof. I often forgot that aliases don't work well with it, as displayed here :)
>
> It is called
>
> __traits(identifier)
>
> .stringof should never be used outside of debugging messages.

__traits(identifier) doesn't work either.

See:

https://run.dlang.io/is/9cDdra
« First   ‹ Prev
1 2 3
Next ›   Last »