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
5 days ago
Nick Treleaven
3 days ago
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