dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte.
Why bring more ctfe call by remmove octal literal ?
Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
November 03 why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Why bring more ctfe call by remmove octal literal ? |
November 03 Re: why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to d007 | On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote: >dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Why bring more ctfe call by remmove octal literal ? What are you even saying? |
November 03 Re: why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to d007 | On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote: >dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Some ctfe and templates are slow. Usually larger functions or array/string append loops end up being to blame. Octal literals don't really matter either way because they're so small. |
November 03 Re: why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to d007 | On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote: >dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Why bring more ctfe call by remmove octal literal ? octal literals are extremely error prone, because people sometimes use leading zeroes for alignment, not realizing that it means the number is completely different. Actual correct octal literal use is vanishingly small. Banning C-style octal literals just makes it so the compiler flags unintended errors like this. -Steve |
November 06 Re: why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 3 November 2023 at 15:34:37 UTC, Steven Schveighoffer wrote: >On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote: >dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Why bring more ctfe call by remmove octal literal ? octal literals are extremely error prone, because people sometimes use leading zeroes for alignment, not realizing that it means the number is completely different. Actual correct octal literal use is vanishingly small. Banning C-style octal literals just makes it so the compiler flags unintended errors like this. -Steve Thanks you all for explain. In my opinion, use some thing like 0o700 will be a better solution compare to template. |
November 05 Re: why remove octal literal support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to d007 | On Sunday, November 5, 2023 9:59:22 PM MST d007 via Digitalmars-d-learn wrote:
> On Friday, 3 November 2023 at 15:34:37 UTC, Steven Schveighoffer
>
> wrote:
> > On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote:
> >> dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte.
> >>
> >>
> >> Why bring more ctfe call by remmove octal literal ?
> >
> > octal literals are extremely error prone, because people sometimes use leading zeroes for alignment, not realizing that it means the number is completely different.
> >
> > Actual correct octal literal use is vanishingly small. Banning C-style octal literals just makes it so the compiler flags unintended errors like this.
> >
> > -Steve
>
> Thanks you all for explain.
>
>
> In my opinion, use some thing like 0o700 will be a better solution compare to template.
I general, D's approach at this point is to have a solution be in the standard library rather than in the language if it doesn't need to be in the language. And in this case, not only does a template solve the problem quite easily, but it's solving a problem that only rarely needs to be solved these days.
So, while some might prefer a language solution, this really isn't the sort of problem that D is likely to solve in the language at this point.
- Jonathan M Davis
|