View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000718LDMud 3.5LPC Compiler/Preprocessorpublic2010-01-26 09:072014-02-24 00:03
Reporterzesstra Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000718: Disallow assignments of 'void' values to variables
DescriptionIt should not be possible to assign void to variables, even to mixed, because it is not possible to declare a variable as being 'void':
mixed a = voidfun(); // works
void a = voidfun(); // error
(Or the other way: 'void' defines that a function returns nothing and you should not assign something which doesn't exist (the non-existing return value))
TagsNo tags attached.

Relationships

related to 0000829 resolvedGnomi LDMud void * 
child of 0000719 resolvedGnomi LDMud 3.5 Disallow returning values from void functions 
child of 0000765 resolvedGnomi LDMud 3.5 Disallow the processing of void values 

Activities

Sorcerer

2010-01-26 09:50

updater   ~0001705

Since an assignment <var> = voidfun(); in a program can only be one of two: an oversight or even an error by the programmer, I recommend throwing an error (type mismatch) in that case.
At least I cannot imagine any reason why someone should want to do this on purpose.

zesstra

2010-01-26 11:28

administrator   ~0001706

Yes, I would also like an error in that case.
BTW: I can't see any sense either in the following assignments, which are possible right now (even with #pragma strict_types,pedantic):
int a = (int)voidfun();
string a = (string)voidfun();
...

fufu

2010-01-26 12:23

manager   ~0001708

One possible reason to do that, and I'm not saying that it is a good one, is that

  int a;
  a = (int)voidfun();

costs one eval-tick less than

  int a;

  voidfun();
  a = 0;

Historically, there was the idiom

  return (int)notify_fail("blah");

but notify_fail has been returning int for ages now. But people may still be doing this for other functions returning void.

zesstra

2010-01-26 15:04

administrator   ~0001709

Ok, so basically as an idiom for assigning 0 (surprise *g*).
Despite your not-recommendation, I have to comment from the viewpoint of someone maintaining domain code: This is ssoooooooooooooo ugly to read as someone who has to maintain the code later, that it is IMHO never justified for saving just one tick. (If I don't know voidfun(), I have to look that up first, instead of just seeing the assignment of a constant 0.)
(BTW: your example can of course be shorted to 'int a; voidfun()' without any assignment, but one can assume an assignment to a != 0 before. ;-) )

The same holds true for return (int)notify_fail("blah"); which is much more readable in the form of notify_fail("blah"); return 0;

sinnvoll

2010-02-10 10:34

reporter   ~0001712

In the moment there is Code like:

private int sitzobjekt_register_im_p()
{
   "/p/Registry/registry"->register(__FILE__);
}
private int sitzobjekt_dummy_p = sitzobjekt_register_im_p();

This collects all uses of a inherit.
There is space wasted for an integer.

If we had void-Variables, then Code could be executed in variable
initialisation time without wasting space.

zesstra

2010-02-10 15:02

administrator   ~0001713

I am not sure, what you are advocating for. Are you arguing that we should go in the other direction and deliberately introduce 'void' as type you could chose for variables?

Variables (or better: svalues) internally consume the same amount of space, no matter of the type. That holds true for 'void' as well. (Actually, any void is technically an int with the value 0.) Therefore size-wise and speed-wise it does not matter at all, if you use
private int sitzobjekt_dummy_p = sitzobjekt_register_im_p();
or a hypothetical
private void sitzobjekt_dummy_p = sitzobjekt_register_im_p();

If you want to save the variable, the better way is IMHO to include it in the H_CREATE* hooks and require all conforming programs (code-style issue) to call the inherited create hooks (there is a feature request for enforcing this technically, but that is rather low on priority...)

zesstra

2010-11-21 01:37

administrator   ~0001931

If there are not serious objections very soon, I will make TYPE_VOID incompatible to anything else in compatible_types() in the compiler.

BTW: Interestingly, TYPE_VOID is already incompatible to anything else in check_rtt_compatibility() in the interpreter.

zesstra

2010-11-23 00:43

administrator   ~0001934

Unassign until it is clear how we best proceed with 0000765.

zesstra

2014-02-24 00:03

administrator   ~0002235

Should be fixed with 0000721.

Issue History

Date Modified Username Field Change
2010-01-26 09:07 zesstra New Issue
2010-01-26 09:50 Sorcerer Note Added: 0001705
2010-01-26 11:28 zesstra Note Added: 0001706
2010-01-26 12:23 fufu Note Added: 0001708
2010-01-26 15:04 zesstra Note Added: 0001709
2010-02-10 10:34 sinnvoll Note Added: 0001712
2010-02-10 15:02 zesstra Note Added: 0001713
2010-11-21 01:07 zesstra Relationship added child of 0000719
2010-11-21 01:37 zesstra Note Added: 0001931
2010-11-21 01:37 zesstra Assigned To => zesstra
2010-11-21 01:37 zesstra Status new => assigned
2010-11-23 00:19 zesstra Relationship added child of 0000765
2010-11-23 00:43 zesstra Note Added: 0001934
2010-11-23 00:43 zesstra Assigned To zesstra =>
2010-11-23 00:43 zesstra Status assigned => confirmed
2014-02-23 23:56 zesstra Relationship added related to 0000829
2014-02-24 00:02 zesstra Status confirmed => assigned
2014-02-24 00:02 zesstra Assigned To => Gnomi
2014-02-24 00:03 zesstra Note Added: 0002235
2014-02-24 00:03 zesstra Status assigned => resolved
2014-02-24 00:03 zesstra Fixed in Version => 3.5.0
2014-02-24 00:03 zesstra Resolution open => fixed