Thread overview
enum strings in import
Apr 27, 2022
IGotD-
May 02, 2022
Quirin Schroll
May 02, 2022
IGotD-
May 03, 2022
Anonymouse
May 04, 2022
Nick Treleaven
May 03, 2022
user1234
May 04, 2022
user1234
May 09, 2022
Meta
May 10, 2022
Basile B.
April 27, 2022

Reading this concept it is clear that we need to change import to allow enum strings.

https://github.com/dlang/phobos/pull/8309

It can be done with mixins but the code becomes ugly. Instead compile time string enums should be accepted in the import argument.

The question is how to do this.

enum string somewhere = "location";

import this.that.somewhere.here;

This might fool many users and they start to look for the folder "somewhere" which might not exist. In order to clarify that you are using a compile time string you can be more obvious like.

import this.that.enum(somewhere).here;

Now it is more obvious that somewhere is a variable.

Another thing that I also noticed is how the version identifiers are just a sea of identifiers, many not orthogonal. Wouldn't it be time to let version have an argument. Like

version(OS == Windows)
{

}

This would it simpler for the import, then we could use.

import this.that.version(OS).here;

May 02, 2022

On Wednesday, 27 April 2022 at 15:23:32 UTC, IGotD- wrote:

>

Reading this concept it is clear that we need to change import to allow enum strings.

https://github.com/dlang/phobos/pull/8309

It can be done with mixins but the code becomes ugly. Instead compile time string enums should be accepted in the import argument.

The question is how to do this.

enum string somewhere = "location";

import this.that.somewhere.here;

This might fool many users and they start to look for the folder "somewhere" which might not exist. In order to clarify that you are using a compile time string you can be more obvious like.

import this.that.enum(somewhere).here;

Now it is more obvious that somewhere is a variable.

Another thing that I also noticed is how the version identifiers are just a sea of identifiers, many not orthogonal. Wouldn't it be time to let version have an argument. Like

version(OS == Windows)
{

}

This would it simpler for the import, then we could use.

import this.that.version(OS).here;

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers. So you’d have

import a.b.mixin(somwhere).here;

This has been proposed like a thousand times.

May 02, 2022

On Monday, 2 May 2022 at 12:03:20 UTC, Quirin Schroll wrote:

>

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers. So you’d have

import a.b.mixin(somwhere).here;

This has been proposed like a thousand times.

Sounds reasonable.

So this according to your claim has been proposed many times but nothing happened.

May 03, 2022

On Monday, 2 May 2022 at 12:03:20 UTC, Quirin Schroll wrote:

>

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers.

mixin("someInt") = 5 works today, so I was actually surprised to see import mixin("some.module") doesn't.

May 03, 2022

On Monday, 2 May 2022 at 12:03:20 UTC, Quirin Schroll wrote:

>

On Wednesday, 27 April 2022 at 15:23:32 UTC, IGotD- wrote:

>

[...]

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers.

No change is required to mixins.

A mixin that gives an expression would work. From the resulting expression you can trivially extract Identifier(s) from IdentExp or chain of them.

May 04, 2022

On Tuesday, 3 May 2022 at 17:41:55 UTC, Anonymouse wrote:

>

On Monday, 2 May 2022 at 12:03:20 UTC, Quirin Schroll wrote:

>

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers.

mixin("someInt") = 5 works today,

That is because the left hand side is an expression. There are many cases where an identifier is expected but a string mixin is not supported, particularly in declarations. I think when people learn about string mixins they assume they will work everywhere, then run into errors.

May 04, 2022

On Tuesday, 3 May 2022 at 20:47:25 UTC, user1234 wrote:

>

On Monday, 2 May 2022 at 12:03:20 UTC, Quirin Schroll wrote:

>

On Wednesday, 27 April 2022 at 15:23:32 UTC, IGotD- wrote:

>

[...]

The simplest solution is to allow mixin(expression) not only to generate declarations, expressions and statements, but also to generate identifiers.

No change is required to mixins.

A mixin that gives an expression would work. From the resulting expression you can trivially extract Identifier(s) from IdentExp or chain of them.

https://www.youtube.com/watch?v=44h6GzF7izU

May 09, 2022

On Wednesday, 4 May 2022 at 18:00:21 UTC, user1234 wrote:

>

https://www.youtube.com/watch?v=44h6GzF7izU

Completely off-topic, this song is an absolute banger.

May 10, 2022

On Monday, 9 May 2022 at 19:14:38 UTC, Meta wrote:

>

On Wednesday, 4 May 2022 at 18:00:21 UTC, user1234 wrote:

>

https://www.youtube.com/watch?v=44h6GzF7izU

Completely off-topic, this song is an absolute banger.

Yeah, old-school use of YT too. People used it to share music and did not give a shit about channels, live streams, and (sight) "shorts".