V: [Bug] Optionals need to be assigned to temporary variables.

Created on 17 Sep 2020  Â·  12Comments  Â·  Source: vlang/v

V version:

> v -v
Current V version:
V 0.1.29 35cbca9

OS: Win10 2004

What did you do?

// ./hello.v:

import os

fn main() {
    print("./rand: " + os.read_file("./rand")?)
}

```cmd

v run "d:projectsvhellohello.v"



### What did you expect to see?
It successfully compile.

### What did you see instead?
```cmd
==================
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c: In function 'main__main':
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c:10041:49: error: expected expression before 'Option_string'
  print(string_add(tos_lit("hewwo, heres rand"), Option_string _t191 = os__read_file(tos_lit("./rand"));
                                                 ^~~~~~~~~~~~~
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c: In function '_vinit':
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c:10070:38: warning: integer constant is so large that it is unsigned
  _const_math__bits__max_u64 = ((u64)(18446744073709551615));
                                      ^~~~~~~~~~~~~~~~~~~~
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c:10097:409: warning: integer constant is so large that it is unsigned
   ((u64)(1)), ((u64)(10)), ((u64)(100)), ((u64)(1000)), ((u64)(10000)), ((u64)(100000)), ((u64)(1000000)), ((u64)(10000000)), ((u64)(100000000)), ((u64)(1000000000)), ((u64)(10000000000)), ((u64)(100000000000)), ((u64)(1000000000000)), ((u64)(10000000000000)), ((u64)(100000000000000)), ((u64)(1000000000000000)), ((u64)(10000000000000000)), ((u64)(100000000000000000)), ((u64)(1000000000000000000)), ((u64)(10000000000000000000))}));
                                                                                                                                                                                                                                                                                                                                                                                                                         ^~~~~~~~~~~~~~~~~~~~
C:\Users\aqilc\AppData\Local\Temp\v\hello.tmp.c: In function 'wmain':
...
==================
(Use `v -cg` to print the entire error message)

builder error: 
==================
C error. This should never happen.
Bug

Most helpful comment

Another (clearer) reproduction:

fn foo() ?int {
    return 1
}

fn bar(i int) {
    println(i)
}

bar(foo()?)
// edit: `bar(foo() or { 1 })` causes a C error as well

It's not the same issue as #6392 (hence why we suggested opening two), the code above contains two related but different issues.

Also, note that

fn foo() ?int {
    return 1
}

println(foo()?) // error: cannot print optional type

currently gives a V error, yet it should not imho, as the error is being handled correctly.

All 12 comments

BTW, shouldn't this behavior be better performance-wise than storing everything in variables too? Why hasn't anyone used this and found out this was an issue?

Probably because most people wouldn't bother writing a tiny program just to print the contents of a file, when the system already has cat or type or less or more or... any number of other utilities already available, depending on the OS.

Thanks for reporting this, though. If something is not allowed, you should always get a V error, not a C error.

What if this was used to even further optimize larger programs? Writing something to memory then printing can be expensive in the place of just straight up piping.

This isn't just talking about a read_file, but all optionals in general too. If you wanted to write a quick hacky HTTPS server that worked as a proxy and just wanted the results to be transferred quickly, this would be a better solution. It's more readable and gets data into your output more efficiently.

The bug text seems the same as https://github.com/vlang/v/issues/6392, I suggest we close this in favour of the other one with more descriptive title.

@ntrel I was told to make two by spaceface and spytheman, so I did. If they feel too similar, I guess you can close them. ¯_(ツ)_/¯

@AqilCont I don't understand the comments here, I'm just going by the bug description, which seems exactly the same - am I missing something?

Another (clearer) reproduction:

fn foo() ?int {
    return 1
}

fn bar(i int) {
    println(i)
}

bar(foo()?)
// edit: `bar(foo() or { 1 })` causes a C error as well

It's not the same issue as #6392 (hence why we suggested opening two), the code above contains two related but different issues.

Also, note that

fn foo() ?int {
    return 1
}

println(foo()?) // error: cannot print optional type

currently gives a V error, yet it should not imho, as the error is being handled correctly.

@spaceface777 thanks for explaining, I missed the ?.

Sorry for not being clear! I don't have too much time to answer because of school so I really appreciate the detailed description from @spaceface777 :D

@AqilCont my fault, thanks for filing both issues. I was confused as the C error is the same for both.

No problem! My issues were probably cryptic anyways, need more experience writing them. I got the errors when I was running the same program with little modification(literally a ? to fix that typeerror), and I am not a C programmer so I barely understood the errors. I just posted them without thinking it through, and that's my fault.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

XVilka picture XVilka  Â·  3Comments

medvednikov picture medvednikov  Â·  3Comments

choleraehyq picture choleraehyq  Â·  3Comments

cjmxp picture cjmxp  Â·  3Comments

radare picture radare  Â·  3Comments