Is there a simpler way that this?

struct Hex {}
immutable Hex hex;

I don't want to introduce two names in the scope, just `hex`. Another attempt:

immutable hex = function {};

That's a bit... arcane. Is there another simple way? Thanks!

On Sunday, 14 March 2021 at 16:37:58 UTC, Andrei Alexandrescu wrote:
> Is there a simpler way that this?
>
> struct Hex {}
> immutable Hex hex;
>
> I don't want to introduce two names in the scope, just `hex`. Another attempt:
>
> immutable hex = function {};
>
> That's a bit... arcane. Is there another simple way? Thanks!

You could use a Voldemort type:

    immutable hex = () {
        static struct Hex {}
        return Hex();
    }();

On Sunday, 14 March 2021 at 16:37:58 UTC, Andrei Alexandrescu wrote:
> Is there a simpler way that this?
>
> struct Hex {}
> immutable Hex hex;
>
> I don't want to introduce two names in the scope, just `hex`. Another attempt:
>
> immutable hex = function {};
>
> That's a bit... arcane. Is there another simple way? Thanks!

Hardly simpler, but Hex can be kept out of scope by making it Voldemort:

    immutable hex = (){struct Hex{} return Hex();}();

-- Bastiaan.

On Sunday, 14 March 2021 at 16:37:58 UTC, Andrei Alexandrescu wrote:
> Is there a simpler way that this?
>
> struct Hex {}
> immutable Hex hex;
>
> I don't want to introduce two names in the scope, just `hex`. Another attempt:
>
> immutable hex = function {};

Could be slightly shorter:

const u = (){};

> That's a bit... arcane. Is there another simple way? Thanks!

Indeed, though what is your use case? Usually the use case determines whether a solution is good or not.

Is JavaScript's Symbol [1] primitive data type something like what you're after?

Perhaps anonymous classes would be closest D can offer - `auto a = new class {};`. Unfortunately, unlike struct values, classes objects can't pass through from CTFE to RT, which makes them limited for certain use cases (e.g. you can't put the statement above at the module scope).

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Symbol

On Sunday, 14 March 2021 at 19:10:19 UTC, Petar Kirov [ZombineDev] wrote:
> Unfortunately, unlike struct values, classes objects can't pass through from CTFE to RT, which makes them limited for certain use cases (e.g. you can't put the statement above at the module scope).

Yes they can. The limitation is class objects cannot be enums and passing as template arguments is not allowed (I believe the error is caught at codegen though so avoid codegen, avoid error, but still).

But you can assign them to static values post ctfe.


I think you could make a little function to convert a class to a struct too

	immutable bar = new class { int a; }.toStruct;

That is totally possible, but the implementation of toStruct is a slight pain, keeping the identifiers and such. I don't think it is worth the hassle.

On Sunday, 14 March 2021 at 19:23:33 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 March 2021 at 19:10:19 UTC, Petar Kirov [ZombineDev] wrote:
>> Unfortunately, unlike struct values, classes objects can't pass through from CTFE to RT, which makes them limited for certain use cases (e.g. you can't put the statement above at the module scope).
>
> Yes they can. The limitation is class objects cannot be enums and passing as template arguments is not allowed (I believe the error is caught at codegen though so avoid codegen, avoid error, but still).
>
> [...]

I think my point still stands :P

You can use class objects inside CTFE, but they can't exit unchanged - you can't really use them to initialize class variables and more importantly, if you convert a class object to a struct value, you loose the object identity, so you can't quite emulate [1].

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Symbol

On 3/14/2021 9:37 AM, Andrei Alexandrescu wrote:
> Another attempt:
> 
> immutable hex = function {};

That won't have a unique type.

It may not have a unique value, either. The compiler/linker may merge identical immutable objects.

On Sunday, 14 March 2021 at 16:37:58 UTC, Andrei Alexandrescu wrote:
> struct Hex {}
> immutable Hex hex;

What about making the type name optional (via a language change) and allow

    immutable struct { int x; int y; } hex;

and if possible have it be lowered to a builtin tuple

    immutable (int, int) hex;

?

Does a struct and tuple with the same fields have the same memory layout?

On Monday, 15 March 2021 at 09:45:44 UTC, Per Nordlöw wrote:
> and if possible have it be lowered to a builtin tuple
>
>     immutable (int, int) hex;

Forget about the tuple lowering. It doesn't have the fields accessible by name.

On Monday, 15 March 2021 at 09:45:44 UTC, Per Nordlöw wrote:
> On Sunday, 14 March 2021 at 16:37:58 UTC, Andrei Alexandrescu wrote:
>> struct Hex {}
>> immutable Hex hex;
>
> What about making the type name optional (via a language change) and allow
>
>     immutable struct { int x; int y; } hex;
>
> and if possible have it be lowered to a builtin tuple
>
>     immutable (int, int) hex;
>
> ?
>
> Does a struct and tuple with the same fields have the same memory layout?

Some kind of lowering would hopefully be a way of getting tuples that work. Tuples-as-compiler-magic are embarrassing, tuples as a library are too complicated I find.

i.e. The tuple should be either a sister or close-child of a struct