www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Specify rhs at initialisation or assignment of typedef' d variable

reply Cecil Ward <d cecilward.com> writes:
Say I have used Typedef! to create some new type and I declare a 
variable, constant or enum of that type. Is there a way that I 
can express a literal value on the rhs without having to use 
casts, as that seems to defeat the point of the nice type safety?

I may be asking for the impossible or _illogical_ here. In any 
case, I still get to keep the nice feature of not being able to 
mix up types with assignment from one variable to another.

Specific example is

     mac_addr_48_t   my_mac_address = 0x112233445566uL;

Which now produces a compile time error after I changed to use an 
alias  = Typedef!uint64_t as opposed to just a straight alias = 
uint64_t earlier with no strong typing.
Jul 31 2017
parent reply inevzxui <inevzxui inevzxui.ui> writes:
On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote:

 Say I have used Typedef! to create some new type and I declare 
 a variable, constant or enum of that type. Is there a way that 
 I can express a literal value on the rhs without having to use 
 casts, as that seems to defeat the point of the nice type 
 safety?

 I may be asking for the impossible or _illogical_ here. In any 
 case, I still get to keep the nice feature of not being able to 
 mix up types with assignment from one variable to another.

 Specific example is

     mac_addr_48_t   my_mac_address = 0x112233445566uL;

 Which now produces a compile time error after I changed to use 
 an alias  = Typedef!uint64_t as opposed to just a straight 
 alias = uint64_t earlier with no strong typing.


If struct + alias this is not strong enough the only solution is 
see is a helper template à la "octal" or "hexString", i.e a 
static cally checked string.
Jul 31 2017
parent reply Cecil Ward <d cecilward.com> writes:
On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote:

 On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote:

 Say I have used Typedef! to create some new type and I declare 
 a variable, constant or enum of that type. Is there a way that 
 I can express a literal value on the rhs without having to use 
 casts, as that seems to defeat the point of the nice type 
 safety?

 I may be asking for the impossible or _illogical_ here. In any 
 case, I still get to keep the nice feature of not being able 
 to mix up types with assignment from one variable to another.

 Specific example is

     mac_addr_48_t   my_mac_address = 0x112233445566uL;

 Which now produces a compile time error after I changed to use 
 an alias  = Typedef!uint64_t as opposed to just a straight 
 alias = uint64_t earlier with no strong typing.


 If struct + alias this is not strong enough the only solution 
 is see is a helper template à la "octal" or "hexString", i.e a 
 static cally checked string.


I suspect that I am asking for something that literally makes no 
sense at all. I wanted to try and avoid opening the door to 
allowing the following kind of typing error now, eg
     enum ip_address = 0x11223344;
     mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address;
as if we are going to the bother of introducing strong type 
checking with Typedef! then the last thing I want to do is 
encourage is a proliferation of casts.

I realise something else now too -

Issue 2: The thing is that I also immediately have to do a lot of 
work to make the simplest operators work anyway, such as in

     foreach( addr;  base_mac_address .. base_mac_address + range )

where the + operator is producing compile-time errors now.

So it just seems that the Typedef! feature immediately make life 
into a nightmare. I don't know if something based of the physical 
units module (using 'dimensionless' in this case) would work - 
perhaps it only handles floating point of various types? Or 
whether that would also involve a huge amount of work and still 
have issue 1 mentioned earlier. In any case, I have absolutely no 
clue how to even begin to start using the units module thing.
Jul 31 2017
next sibling parent Cecil Ward <d cecilward.com> writes:
On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote:

 On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote:

 [...]


 I suspect that I am asking for something that literally makes 
 no sense at all. I wanted to try and avoid opening the door to 
 allowing the following kind of typing error now, eg
     enum ip_address = 0x11223344;
     mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address;
 as if we are going to the bother of introducing strong type 
 checking with Typedef! then the last thing I want to do is 
 encourage is a proliferation of casts.

 [...]


Actually, it would be really nice to have some kind of safe 
initialisation helper that checks value ranges, as in this 
particular case I need to make sure that the literal 64-bit value 
fits in 48 bits.
Jul 31 2017
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote:

 [ ... ]
 I suspect that I am asking for something that literally makes 
 no sense at all. I wanted to try and avoid opening the door to 
 allowing the following kind of typing error now, eg
     enum ip_address = 0x11223344;
 [ ... ]


Please have a look at the bigEndian function and BigEndian struct 
in SQLite-D

https://github.com/UplinkCoder/sqlite-d/blob/master/source/utils.d

The point here is writing your own struct and using alias-this 
yourself.
Then you only need a function to produce constants of the right 
type.
Such a function should be trivially CTFEable
Jul 31 2017