Jump to page: 1 2
Thread overview
[Issue 24520] [REG] type(value) got a synonym (type)(value)
[Issue 24520] [REG] C-style casts are now accepted (sometimes)
Apr 24
ponce
Apr 24
ponce
Apr 24
ponce
Apr 24
Dennis
Apr 24
ponce
Apr 24
ponce
Apr 25
ponce
Apr 26
ponce
May 01
Dlang Bot
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

--- Comment #1 from ponce <aliloko@gmail.com> ---
https://d.godbolt.org/z/Wqc17Gs8P

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

ponce <aliloko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, spec
           Hardware|x86                         |All
                 OS|Windows                     |All
           Severity|enhancement                 |regression

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch

--- Comment #2 from timon.gehr@gmx.ch ---
https://issues.dlang.org/show_bug.cgi?id=24025

As Steven says:

> An alternative to delaying the C style cast to semantic is to just remove the error.
>
> If a cast from C is desired, then it will work if the type can be constructed with that parameter.
>
> Back when this error was created, something like `int(5)` was not valid code. Now it is. So most cases of casting will just have a failed implicit cast error.
>
> Ironically, this error *hurts* porting C code, instead of helping.

Therefore, I believe the change in behavior with "casts" is intentional.

(int)(c % 8) is just treated as another way to write int(c % 8). Similar to how
`(f)(1, 2)` just means `f(1, 2)`.

I do appreciate that grammar changes make it harder to write code that is compatible with multiple compiler versions, but I also think testing with different compiler versions cannot be avoided if one wants to support them.

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

--- Comment #3 from ponce <aliloko@gmail.com> ---
I get that this is unable to create dysfunction other than "doesn't build".

My issue is that a silent language change with no changelog entry and no spec change. This issue is exactly similar with introduction of named arguments.

Perhaps yes the language is better afterwards; but since there is no way to know, there is no knowledge one has to test things that worked for a long time under compilers that are a few versions back.

If this happen like this, then Editions when compiled with new compilers, won't work in old compilers, somewhat bypassing the advantage of Editions.

I develop libraries with users and we do not have the same compilers, so users expect me to test with multiple compilers yes but it is helpful to have a way to track breaking changes or additions like these in changelog. And it's not sure if intentional here.

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |
                 CC|                            |dkorpel@live.nl

--- Comment #4 from Dennis <dkorpel@live.nl> ---
> it is helpful to have a way to track breaking changes or additions like these in changelog

It is listed in the changelog of 2.105:

> DMD Compiler bug fixes
> (...)
> 29. Bugzilla 24025: Expressions contained in parentheses should not be assumed to be C casts

It doesn't have a spec change because the grammar already allowed calling a parenthesized expression. It's only an implementation bug that it was considered a C-style cast. While breaking changes warrant an explicit changelog entry, fixes for rejects-valid bugs usually only require a bugzilla issue to be closed. Is that something you want to see changed?

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

--- Comment #5 from ponce <aliloko@gmail.com> ---
I admit it's not entirely clear to me if the semantics of cast() are the same as implicit conversions. Haven't found a counter-example though, even with alias this.

--
April 24
https://issues.dlang.org/show_bug.cgi?id=24520

--- Comment #6 from ponce <aliloko@gmail.com> ---
In changelog it's in:

"DMD Compiler bug fixes"

section. But grammar changes are usually language changes, so it could be easier to anticipate if there was a Language Change section (which I will read, more likely that the ~30 items in bug fixes).

Thought I understand that in this case it's believed to not change semantics.

--
April 25
https://issues.dlang.org/show_bug.cgi?id=24520

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[REG] C-style casts are now |[REG] type(value) got a
                   |accepted (sometimes)        |synonym (type)(value)

--- Comment #7 from anonymous4 <dfj1esp02@sneakemail.com> ---
It's believed that grammar allows this syntax and grammar didn't recently change, therefore it's not a change in grammar, but a compiler bug fix.

--
April 25
https://issues.dlang.org/show_bug.cgi?id=24520

--- Comment #8 from ponce <aliloko@gmail.com> ---
Maybe I was unpleasant to report that, but you can be unpleasant with your real name instead of an anonymous id.

--
April 26
https://issues.dlang.org/show_bug.cgi?id=24520

ponce <aliloko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from ponce <aliloko@gmail.com> ---
Fixed by https://github.com/dlang/dlang.org/pull/3810

Thanks Stephen!

https://dlang.org/changelog/2.105.0.html#dmd.allow-parentheses-for-call

--
« First   ‹ Prev
1 2