www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - enum strings in import

reply IGotD- <nise nise.com> writes:
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;
Apr 27 2022
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
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
```D
import a.b.mixin(somwhere).here;
```
This has been proposed like a thousand times.
May 02 2022
next sibling parent IGotD- <nise nise.com> writes:
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
 ```D
 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 02 2022
prev sibling next sibling parent reply Anonymouse <zorael gmail.com> writes:
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
parent Nick Treleaven <nick geany.org> writes:
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
prev sibling parent reply user1234 <user1234 12.de> writes:
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 03 2022
parent reply user1234 <user1234 12.de> writes:
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 04 2022
parent reply Meta <jared771 gmail.com> writes:
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 09 2022
parent Basile B. <b2.temp gmx.com> writes:
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".
May 10 2022