View Issue Details

IDProjectCategoryView StatusLast Update
0000883LDMud 3.6LPC Compiler/Preprocessorpublic2020-09-01 22:37
Reporterzesstra Assigned ToGnomi  
Status resolvedResolutionfixed 
Platformx86_64OSMacOS XOS Version10.9.x
Fixed in Version3.6.3 
Summary0000883: structs: compatibility of inherited (super) struct in place of inheriting (sub) struct
DescriptionA fellow wizard in Morgengrauen sent me the following comment/suggestion:

I played with the struct type and came up with the following snippet:

#pragma strong_types, rtt_checks

struct A {
  int one;

struct B (A) {
  int two;

void test () {
  struct B b = (<A> 100);

This snippet compiles with LD 3.6.2. The assignment in test() is not
type-safe because a super type is assigned to a sub type. The compiler
accepted this and therefore the issue is only signaled at run time
with the error "Bad type for assignment: got 'struct A', expected
'struct B'." Would it be an improvement if the compiler rejected this
as invalid?
TagsNo tags attached.



2020-08-15 10:52

administrator   ~0002546

Last edited: 2020-08-15 10:55

Gnomi pointed out yesterday, that the behaviour is in principle consistent with the handling of other types, especially unions. Indeed, that situation is similar to:
int|float var;
int i;
In this case not only var=i; is allowed at compile-time, but also i=var, because *at runtime* var might actually point to an int and the assignment is legal:
var = 42;
i = var;

In cases of structs it is comparable to this case:
struct A {};
struct C(A) {};
struct A a;
struct C c;
c = a is allowed at compile-time, because at runtime, 'a' might contain an instance of struct C and the compiler in general doesn't know that. (We just don't have a type-tracking in the compiler that is capable of that.)
a = (<C>);
c = a; // valid

However, in this case of struct literals, the compiler does know that the assignment will be illegal at runtime. It would be consequent to dis-allow it at compile-time, like in the case of 'int i = 0.0';
(Although it is arguably a special case and might not be very common.)

Issue History

Date Modified Username Field Change
2020-08-15 10:50 zesstra New Issue
2020-08-15 10:52 zesstra Note Added: 0002546
2020-08-15 10:53 zesstra Note Edited: 0002546
2020-08-15 10:55 zesstra Note Edited: 0002546
2020-08-24 18:57 Gnomi Assigned To => Gnomi
2020-08-24 18:57 Gnomi Status new => assigned
2020-09-01 22:37 Gnomi Project LDMud => LDMud 3.6
2020-09-01 22:37 Gnomi Status assigned => resolved
2020-09-01 22:37 Gnomi Resolution open => fixed
2020-09-01 22:37 Gnomi Fixed in Version => 3.6.3