On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> [...]
>
> I have long wanted to offer but there was no suitable place. I would like to propose to trivial rename standart type names by this way:
>
> int -> int32
> ulong -> uint64
> float -> float32
> double -> float64
> byte -> octet
>
> Reason:
>
> Most developers no longer remember where these names came from and why it are so called. In the future this number will close to 100%. And soon we will have access to all sorts of non-standard FPGA implemented CPUs with a different byte size, for example.
>
> (It will also break existing code very reliably and it will be difficult to confuse up code of different Dlang versions.)

Absolutely! But I think it is not necessary to rename.
For me it is enough to create aliases in object.d, I did it personally in my implementation of druntime to port D to AVR (It is not yet public)

On Saturday, 28 March 2020 at 18:00:01 UTC, Ernesto Castellotti wrote:

>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
>>
>> Reason:
>>
>> Most developers no longer remember where these names came from and why it are so called. In the future this number will close to 100%. And soon we will have access to all sorts of non-standard FPGA implemented CPUs with a different byte size, for example.
>>
>> (It will also break existing code very reliably and it will be difficult to confuse up code of different Dlang versions.)
>
> Absolutely! But I think it is not necessary to rename.

Then everyone why comes from D2 will use old names and there can be confusion.

On Sat, Mar 28, 2020 at 09:12:17AM +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2020-03-27 21:25, H. S. Teoh wrote:
> 
> > There's already dfix.  Does it not work well enough?  What are the issues the prevent us from using it in general?
> 
> It's not good enough. It's not based on the DMD frontend, it uses its own parser. It doesn't do any semantic analysis. As long as the DMD frontend is not used, it will always play catch up and will most likely never do semantic analysis.
[...]

But how could it use the DMD frontend if its job is to fix old syntax rejected by the new compiler into new syntax acceptable to the new compiler?  Would it have to use two copies of the frontend, one for older syntax and one for newer syntax?


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

On Saturday, 28 March 2020 at 17:28:59 UTC, IGotD- wrote:
> On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin wrote:
>>
>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
>>
>
> In this case wouldn't it be better to rename them to shorter u8, i8 .. u64, i64 and f32 .. f64. This is actually not a breaking change and we can implement it today if we want to with the old type names still there. Also, you can make whatever alias you want.

How is it not a breaking change?

On Saturday, 28 March 2020 at 17:40:45 UTC, Denis Feklushkin wrote:
> On Saturday, 28 March 2020 at 17:29:57 UTC, Les De Ridder wrote:
>
>>> byte -> octet
>>
>> You could make an argument for the other ones, but I'm pretty sure
>> everyone understands what is meant by 'byte' 99% of the time.
>
> At this decade.
>
> I specifically wrote remark about FPGA. Creating new processors becomes easy as creating software for them.
>
> In the future we will have a lot of different processors inside of PC case. I can easily imagine special purpose CPU with byte sized 6 or 16. So as for me it’s better to get rid of this name, since in the very first version of D language it was declared that standard types are platform independent (except size_t of course).

I think octet would be confusing, even if it's technically more correct. Most people are aware of what byte means, they wouldn't know what octet is. Alternatively, byte type could just be dropped and uint8 should be used instead.

On Saturday, 28 March 2020 at 18:40:30 UTC, JN wrote:

> I think octet would be confusing, even if it's technically more correct. Most people are aware of what byte means, they wouldn't know what octet is. Alternatively, byte type could just be dropped and uint8 should be used instead.

Yes, absolutely right

On Saturday, 28 March 2020 at 17:40:45 UTC, Denis Feklushkin wrote:
> On Saturday, 28 March 2020 at 17:29:57 UTC, Les De Ridder wrote:
>
>>> byte -> octet
>>
>> You could make an argument for the other ones, but I'm pretty sure
>> everyone understands what is meant by 'byte' 99% of the time.
>
> At this decade.
>
> I specifically wrote remark about FPGA. Creating new processors becomes easy as creating software for them.
>
> In the future we will have a lot of different processors inside of PC case. I can easily imagine special purpose CPU with byte sized 6 or 16. So as for me it’s better to get rid of this name, since in the very first version of D language it was declared that standard types are platform independent (except size_t of course).

Dont design based on imaginings of the future, you will almost always get it wrong.

On Saturday, 28 March 2020 at 17:28:59 UTC, IGotD- wrote:
> On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin wrote:
>>
>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
>>
>
> In this case wouldn't it be better to rename them to shorter u8, i8 .. u64, i64 and f32 .. f64. This is actually not a breaking change and we can implement it today if we want to with the old type names still there. Also, you can make whatever alias you want.

I would love that. This is one of the things that Rust got 100% right.

I know you can make whatever alias you want, but the point is that it's not universally used.  Standarization is important, that's why I'd use the fugly C names in C/C++ even though I could alias them away.

On Saturday, 28 March 2020 at 20:08:18 UTC, krzaq wrote:
> I would love that. This is one of the things that Rust got 100% right.
>
> I know you can make whatever alias you want, but the point is that it's not universally used.  Standarization is important, that's why I'd use the fugly C names in C/C++ even though I could alias them away.

D did standardize, there's no question as to size in D as it is now.

On Saturday, 28 March 2020 at 19:50:44 UTC, NaN wrote:

>
> Dont design based on imaginings of the future, you will almost always get it wrong.

This is almost already reality, not future.

Just make survey around your friends/collegues about: what is a byte? Then compare with wikipedia/dictionary/RFC/etc definition. You will be very surprised.

Already, it is difficult for a beginner to explain why the double is 64 bits. And if it is double from integer why integer is 32. I think it is no need to spend time by explaining whole IT history.

Above wrote that the Rust did something similar. I suppose they went the same way of reasoning.