Delyan Angelov

The current behavior of the sample is to print: ```v [a.v:11] a: 0 [a.v:12] b: 0 ``` which is still wrong, since the `none` was magically transformed into 2 zeros......

Note: ```v struct Handler {} fn (shared h Handler) f() { lock h {} } ``` compiles cleanly, while: ```v struct Handler {} fn (shared h Handler) f() {} ```...

A simpler self contained reproduction is with: ```v pub fn concat[T](a []T, b ...T) []T { mut m := []T{cap: a.len + b.len} m

```v pub fn concat(a [][]string, b ...[]string) [][]string { mut m := [][]string{cap: a.len + b.len} m

This is also fine: ```v pub fn concat[T](a []T, b ...T) []T { mut m := []T{cap: a.len + b.len} m

A valid fix, may be also to extend the error from `vlib/v/checker/fn.v:1009:c.error` to apply to the generic function call as well.

``` #0 17:48:49 ᛋ master /v/vnew❱convert 228573825-542a3f57-908a-4d6a-86e0-2456a773c900.jpg y.jpg #0 17:48:57 ᛋ master /v/vnew❱file 228573825-542a3f57-908a-4d6a-86e0-2456a773c900.jpg y.jpg 228573825-542a3f57-908a-4d6a-86e0-2456a773c900.jpg: RIFF (little-endian) data, Web/P image, VP8 encoding, 338x600, Scaling: [none]x[none], YUV color, decoders should...

I think that we should change all create_image methods in gg, to return results, so that decoding errors could become normal V errors. i.e. instead of: `pub fn (ctx &Context)...

That complicates module lookup, and makes it harder to explain and understand. It also lacks tests.

> windows-gcc job failed due to time restriction in 121 minutes. Not related to change, I think yes, do not worry about it.