Thread overview
Forbid needless pointer casts
Feb 20, 2020
FlameInHeart
Feb 20, 2020
Andre Pany
Feb 20, 2020
FlameInHeart
Feb 22, 2020
tsbockman
Feb 20, 2020
Mathias Lang
Feb 20, 2020
FlameInHeart
February 20, 2020
Hey,

How about forbidding this:

void foo(Monkey* m) {
    Monkey* m2 = cast(Monkey*) m;
}

Pointer casts are potentially nasty when refactoring and the needless ones are easy for the compiler to detect, and probably no-one will find objections to this change.

Just an easy win, isn't it?

(not going to write a DIP for this...)
February 20, 2020
On Thursday, 20 February 2020 at 11:31:17 UTC, FlameInHeart wrote:
> Hey,
>
> How about forbidding this:
>
> void foo(Monkey* m) {
>     Monkey* m2 = cast(Monkey*) m;
> }
>
> Pointer casts are potentially nasty when refactoring and the needless ones are easy for the compiler to detect, and probably no-one will find objections to this change.
>
> Just an easy win, isn't it?
>
> (not going to write a DIP for this...)

There is also the possibility to add this check to DScanner instead of the compiler.
By the way, DScanner is now also easily accessible from Dub.
You can just say `dub lint` and it will check your current dub package.

Kind regards
André
February 20, 2020
...mm, or is there the possibility of a problem with templated or otherwise generated code?
February 20, 2020
On Thursday, 20 February 2020 at 11:31:17 UTC, FlameInHeart wrote:
> Hey,
>
> How about forbidding this:
>
> void foo(Monkey* m) {
>     Monkey* m2 = cast(Monkey*) m;
> }
>
> Pointer casts are potentially nasty when refactoring and the needless ones are easy for the compiler to detect, and probably no-one will find objections to this change.
>
> Just an easy win, isn't it?
>
> (not going to write a DIP for this...)

Why would we forbid something that is legal ? D is usually quite liberal, allowing you to do things as long as they're not obviously wrong. The good thing is that you don't end up "pleasing the compiler" as you do in C++, where you have tons of false positives...

And in this case, it is obviously pointless, but consider generic code:
```
void foo (T) (T* m) {
    T* m2 = cast(Unqual!(T)*) m;
}
```
February 20, 2020
On Thursday, 20 February 2020 at 11:41:18 UTC, Mathias Lang wrote:
> On Thursday, 20 February 2020 at 11:31:17 UTC, FlameInHeart wrote:
...
>> Pointer casts are potentially nasty when refactoring and the

> Why would we forbid something that is legal ?

"Pointer casts are potentially nasty when refactoring"

> And in this case, it is obviously pointless, but consider generic code:
> ```
> void foo (T) (T* m) {
>     T* m2 = cast(Unqual!(T)*) m;
> }
> ```

Yeah...
February 22, 2020
On Thursday, 20 February 2020 at 11:38:22 UTC, FlameInHeart wrote:
> ...mm, or is there the possibility of a problem with templated or otherwise generated code?

Yes, this change would needlessly complicate some template code. Having to write a bunch of extra logic just to prevent a template from emitting harmless no-op code in some circumstances is pretty painful in practice.
December 25
On Thursday, 20 February 2020 at 11:31:17 UTC, FlameInHeart wrote:
> Hey,
>
> How about forbidding this:
>
> void foo(Monkey* m) {
>     Monkey* m2 = cast(Monkey*) m;
> }
>
> Pointer casts are potentially nasty when refactoring and the needless ones are easy for the compiler to detect, and probably no-one will find objections to this change.
>
> Just an easy win, isn't it?
>
> (not going to write a DIP for this...)

Truly, this change would unnecessarily muddle some format code. Composing a lot of additional rationale just to keep a format from emanating innocuous no-operation code in certain conditions is really excruciating by and by.
December 27
On Friday, 25 December 2020 at 15:16:04 UTC, kindouchoud wrote:
> On Thursday, 20 February 2020 at 11:31:17 UTC, FlameInHeart wrote:
>> Hey,
>>
>> How about forbidding this:https://1921681001.id/ , https://19216811.cam/ , https://jpgtopdf.onl/
>>
>> void foo(Monkey* m) {
>>     Monkey* m2 = cast(Monkey*) m;
>> }
>>
>> Pointer casts are potentially nasty when refactoring and the needless ones are easy for the compiler to detect, and probably no-one will find objections to this change.
>>
>> Just an easy win, isn't it?
>>
>> (not going to write a DIP for this...)
>
> Truly, this change would unnecessarily muddle some format code. Composing a lot of additional rationale just to keep a format from emanating innocuous no-operation code in certain conditions is really excruciating by and by.

okey man