Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 31, 2017 Specify rhs at initialisation or assignment of typedef' d variable | ||||
---|---|---|---|---|
| ||||
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. |
July 31, 2017 Re: Specify rhs at initialisation or assignment of typedef' d variable | ||||
---|---|---|---|---|
| ||||
Posted in reply to Cecil Ward | 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.
|
July 31, 2017 Re: Specify rhs at initialisation or assignment of typedef' d variable | ||||
---|---|---|---|---|
| ||||
Posted in reply to inevzxui | 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.
|
July 31, 2017 Re: Specify rhs at initialisation or assignment of typedef' d variable | ||||
---|---|---|---|---|
| ||||
Posted in reply to Cecil Ward | 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.
|
July 31, 2017 Re: Specify rhs at initialisation or assignment of typedef' d variable | ||||
---|---|---|---|---|
| ||||
Posted in reply to Cecil Ward | 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 |
Copyright © 1999-2021 by the D Language Foundation