www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Auto function without return statement, prefer an explicit void

reply Anonymouse <zorael gmail.com> writes:
I like explicit return types. But I also like inference.

```d
struct SomeContainer(T)
{
/* ... */
     auto clear()
     {
         head = 0;
         tail = 0;
         buf[] = T.init;
     }
}
```

dscanner -S: `Auto function without return statement, prefer an 
explicit void`

Can we please have `void clear() auto`?
May 19 2022
next sibling parent reply user1234 <user1234 12.de> writes:
On Thursday, 19 May 2022 at 09:15:50 UTC, Anonymouse wrote:
 I like explicit return types. But I also like inference.

 ```d
 struct SomeContainer(T)
 {
 /* ... */
     auto clear()
     {
         head = 0;
         tail = 0;
         buf[] = T.init;
     }
 }
 ```

 dscanner -S: `Auto function without return statement, prefer an 
 explicit void`

 Can we please have `void clear() auto`?
The problem is when in the body you have an `asm` block that returns. In that case the return type cant be inferred. ```d module runnable ; auto notVoid() { asm { naked; mov AL, 1; ret; } } void main() { auto b = notVoid(); } ```
 Error: variable `runnable.main.b` type `void` is inferred from 
 initializer `notVoid()`, and variables cannot be of type `void`
but `notVoid()` actually returns a `ubyte`
May 19 2022
next sibling parent user1234 <user1234 12.de> writes:
On Thursday, 19 May 2022 at 09:24:21 UTC, user1234 wrote:
 On Thursday, 19 May 2022 at 09:15:50 UTC, Anonymouse wrote:
 I like explicit return types. But I also like inference.

 ```d
 struct SomeContainer(T)
 {
 /* ... */
     auto clear()
     {
         head = 0;
         tail = 0;
         buf[] = T.init;
     }
 }
 ```

 dscanner -S: `Auto function without return statement, prefer 
 an explicit void`

 Can we please have `void clear() auto`?
The problem is when in the body you have an `asm` block that returns. In that case the return type cant be inferred. ```d module runnable ; auto notVoid() { asm { naked; mov AL, 1; ret; } } void main() { auto b = notVoid(); } ```
 Error: variable `runnable.main.b` type `void` is inferred from 
 initializer `notVoid()`, and variables cannot be of type `void`
but `notVoid()` actually returns a `ubyte`
so... we got an error here because we use the function. The D-Scanner check is just here to show you that "hello there might be a small problem here", and that's it ;). Linting is very opritinatrist. The logic is - return type is auto - there's not return statments => take care
May 19 2022
prev sibling parent bauss <jj_1337 live.dk> writes:
On Thursday, 19 May 2022 at 09:24:21 UTC, user1234 wrote:
 On Thursday, 19 May 2022 at 09:15:50 UTC, Anonymouse wrote:
 I like explicit return types. But I also like inference.

 ```d
 struct SomeContainer(T)
 {
 /* ... */
     auto clear()
     {
         head = 0;
         tail = 0;
         buf[] = T.init;
     }
 }
 ```

 dscanner -S: `Auto function without return statement, prefer 
 an explicit void`

 Can we please have `void clear() auto`?
The problem is when in the body you have an `asm` block that returns. In that case the return type cant be inferred. ```d module runnable ; auto notVoid() { asm { naked; mov AL, 1; ret; } } void main() { auto b = notVoid(); } ```
 Error: variable `runnable.main.b` type `void` is inferred from 
 initializer `notVoid()`, and variables cannot be of type `void`
but `notVoid()` actually returns a `ubyte`
Surely we could distinguish an auto function with a return statement / asm that has ret and an auto function that doesn't have any return statements at all.
May 19 2022
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 19 May 2022 at 09:15:50 UTC, Anonymouse wrote:
 I like explicit return types. But I also like inference.

 ```d
 struct SomeContainer(T)
 {
 /* ... */
     auto clear()
     {
         head = 0;
         tail = 0;
         buf[] = T.init;
     }
 }
 ```
Inference is on in this example even with an explicit return type, since you are inside a template. And when you are not, you can make the function a parameterless template. Still, I'm with you in that I disagree somewhat with that no-inferred-void rule. Sometimes it's better to just static assert the return type as void, or not bother with checking it at all. There are times when one does not want templates.
May 19 2022