Thread overview
import(__FILE_LITERAL__)
Sep 09
monkyyy
Sep 09
Daniel N
Sep 09
monkyyy
Sep 09
user1234
Sep 09
monkyyy
Sep 09
user1234
September 09

Import Expressions are limited and had to use in abstractions because they require the user to pass -J=., which given the average d user uses dub; suggesting such a thing requires a 3 step process.

>

Note that by default an import expression will not compile unless one or more paths are passed via the -J switch. This tells the compiler where it should look for the files to import. This is a security feature.

My opinion on the subject may violate the dip forum guidelines.


I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a -J=..

import foo;//lolz
import std;
enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"

By separating it into two step process you could use the special token magic
void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){

September 09

On Monday, 9 September 2024 at 18:18:31 UTC, monkyyy wrote:

>

I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a -J=..

import foo;//lolz
import std;
enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"

By separating it into two step process you could use the special token magic
void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){

I like this idea, I had the same need, although wouldn't it work with parameterless import?

import()
September 09
On Monday, 9 September 2024 at 18:18:31 UTC, monkyyy wrote:
> Import Expressions are limited and had to use in abstractions because they require the user to pass `-J=.`, which given the average d user uses dub; suggesting such a thing requires a 3 step process.
>
>> Note that by default an import expression will not compile unless one or more paths are passed via the -J switch. This tells the compiler where it should look for the files to import. This is a security feature.
>
> My opinion on the subject may violate the dip forum guidelines.
>
> ---
>
> I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a `-J=.`.
>
> ```d
> import foo;//lolz
> import std;
> enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"
> ```
>
> By separating it into two step process you could use the special token magic
> `void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){`

I think that would work but I have two details in mind

1. should it be expanded to a relative or absolute path ? Remember why __FILE_FULL_PATH__ was created.
2. that feature means leaking the file in plain text.

And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ?

In D reflexion is supposed to work with `__traits`.
September 09

On Monday, 9 September 2024 at 19:00:32 UTC, Daniel N wrote:

>

On Monday, 9 September 2024 at 18:18:31 UTC, monkyyy wrote:

>

I suggest that its safe to read the file the user is compiling during compilation. I suggest that new special token that generates ... something that an import expression can take without a -J=..

import foo;//lolz
import std;
enum string=import(__FILE_LITERAL__).split('/n').front;// "import foo;//lolz"

By separating it into two step process you could use the special token magic
void foo(alias file=__FILE_LITERAL__,int line=__LINE__)(){

I like this idea, I had the same need, although wouldn't it work with parameterless import?

import()

Special token sequences are a major source of magic, my compile time counter pattern uses __LINE__ for example

Fundamentally if you want a template to be de-auto-memoized, your probably putting in a a token sequence in the header

September 09
On Monday, 9 September 2024 at 19:33:38 UTC, user1234 wrote:
> 
> And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ?

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

for starters, debugging information without ugly trade offs; alternatives to my `__HERE__` post that no one liked, etc.

> In D reflexion is supposed to work with `__traits`.

and if it fails, or is just slower then what I can parse in 3 seconds of string manipulation?
September 09
On Monday, 9 September 2024 at 20:04:36 UTC, monkyyy wrote:
> On Monday, 9 September 2024 at 19:33:38 UTC, user1234 wrote:
>> 
>> And finally, what's the use of that feature, maybe allow to program a compile-time Quine, but what else ?
>
> https://forum.dlang.org/post/ejkrtibofyeyadrzxgkg@forum.dlang.org
>
> for starters, debugging information without ugly trade offs; alternatives to my `__HERE__` post that no one liked, etc.
>
>> In D reflexion is supposed to work with `__traits`.
>
> and if it fails, or is just slower then what I can parse in 3 seconds of string manipulation?

Yeah you can ignore the remark about __traits. It was because I didn't see the use so I supposed it was eventually to perform some kind of introspection based on parsing, which does not appear to be the motivation.