On 3/7/22 02:27, Per Nordlöw wrote:
> https://forum.dlang.org/post/sdehom$10fi$1@digitalmars.com
>
> On Friday, 23 July 2021 at 13:55:34 UTC, Andrei Alexandrescu wrote:
>
>> If it works well in practice, a future language proposal could take
>> `_import!"std.datetime".SysTime` to the simpler and better
>> `import(std.datetime).SysTime`.
>
> Yes, please!

This seems to be yet another example of the need for template string arguments typed as symbols in the source code.

- Flag!"foo" could become Flag(foo) (or more consistently Flag!foo).

- bitfields could become bitfields!(int, x, 8) instead of bitfields!(int, "x", 8)[*]

Andrei mentioned a couple of times that this is what was discussed as "new alias" in the past where the template allows the use of an "unknown" (or "new") symbol at call site. I see a strong similarity here to the existing opDispatch() that makes compile-time strings from "unknown" symbols at call site.

Ali

[*] I think it would be interesting to come up with a language solution that would e.g. enable combining each three consecutive arguments of bitfields. It is a code smell that everybody knows that the three separate arguments go together but we don't use a language construct for that. We already have the following method in the current language but it is obviously redundant and perhaps that's why the current design of bitfields does not use it:

  bitfields!(Bit(int, x, 8),       // Better but redundant
             Bit(int, y, 8));

A solution that would allow the following would be interesting:

  bitfields!(int x : 8,
             int y : 8);

So, we somehow specify at template definition that two (or three?) parameters (e.g. int and x) can be specified without a comma and perhaps anything after ':' are UDAs of that parameter?

On Monday, 7 March 2022 at 18:45:54 UTC, Ali Çehreli wrote:
> A solution that would allow the following would be interesting:
>
>   bitfields!(int x : 8,
>              int y : 8);
>
> So, we somehow specify at template definition that two (or three?) parameters (e.g. int and x) can be specified without a comma and perhaps anything after ':' are UDAs of that parameter?

There's always strings:

    bitfields!("int x : 8",
               "int y : 8");

On 3/8/22 14:28, Paul Backus wrote:

> There's always strings:

And they are the eyesore! :)

>      bitfields!("int x : 8",
>                 "int y : 8");

But you give me the idea that if we allow "this template parameter is a string" and don't require strings at the use site, then it would work for the above case as well. Basically, the string is contains my domain specific language as you show and I can do anything I want with it.

Brain storming with a 'new string' syntax:

template bitfields(new string args...) {
  // ...
}

  bitfields!(int x : 8,
             int y : 8);

And the template instance sees two strings: "int x : 8" and "int y : 8" and has fun parsing them at compile time. Again, this feels natural to me because it is related to opDispatch.

Of course there are syntax issues: Nothing that takes part in a parameter list can be a part of the string. I think they are just ',' to allow multiple 'new string' parameters and ')' to allow closing the parameter list. When needed, they could be written with backslashes as \, and \).

Wow! I've just written a DIP! :P

Ali

On Tue, Mar 08, 2022 at 03:25:49PM -0800, Ali Çehreli via Digitalmars-d wrote:
> On 3/8/22 14:28, Paul Backus wrote:
> 
> > There's always strings:
> 
> And they are the eyesore! :)
> 
> >      bitfields!("int x : 8",
> >                 "int y : 8");
> 
> But you give me the idea that if we allow "this template parameter is a string" and don't require strings at the use site, then it would work for the above case as well. Basically, the string is contains my domain specific language as you show and I can do anything I want with it.
[...]

Token strings are your friend:

	bitfields!q{ int x:8; int y:8; };

Or, if you like struct-like syntax:

	bitfields!q{
		int x:8;
		int y:8;
	};


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.

On 3/8/22 17:15, H. S. Teoh wrote:

> Token strings are your friend:

I know but they are still strings.

  Flag!"foo" a;  // Meh
  Flag!`foo` b;  // Meh
  Flag!q{foo} c; // No comment... D'oh! :)
  Flag!foo d;    // Unavailable

This is a minor thing only Ali dislikes... :/

Ali

On 3/10/22 22:48, Zach Tollen wrote:

> ::std.datetime:SysTime          // if we put the `::` first it becomes
> viable
>                                  // it's a different version of the `$`
>

Perhaps a second meaning for ..? And is : really necessary? So, would the following work?

  ..std.datetime.Systime

Now it seems to have a different meaning from "importing" though. In this case it feels like we are "using" Systime from that module. And the rationale for .. can be:

- Single dot already means "this module".
- Two dots may mean "outside of this module".

Going off topic and without knowing whether this topic has already been brought up, should inline imports automatically be made available to the callers of functions? Arbitrarily using the $ syntax:

module my.module;

void foo($bar:SomeSymbol a) {
}

Since 'foo' is public to the users of my.module, should we expect the users be able to call 'foo' without importing SomeSymbol separately themselves? And the next question may be what if SomeSymbol is accessible to my.module but not to my users (e.g. if it's 'package'). So, if it should automatically be imported for the users, should SomeSymbol automatically be raised to 'public' status for the users of 'foo'?

Ali