It would be nice if full expressions were allowed at some places that currently only allow variables. For example one of my code files contains the following line:
return istype(t,/turf/area)?initial(t.loc.icon):initial(t.icon)
but if full expressions were allowed as the lhs of the . operator, I could use the shorter line:
return initial((istype(t,/turf/area)?(t.loc):(t)).icon)
This particular example doesn't save much typing but there will probably be many other places where allowing full expressions will enable much more concise code to be written. It would also be useful if assignment expressions had values as in C/C++. I've lost count of the number of compile errors I've had due to typing lines like:
var1=(var2=func(var3=var4))
without paying attention to what language I'm coding in.
It would also be useful if assignment expressions had values as in C/C++. I've lost count of the number of compile errors I've had due to typing lines like:
without paying attention to what language I'm coding in.
Oh, I've got to disagree with you here. I can't tell you the number of hours I've toiled over trival mistakes like:
if(x=2)
which are perfectly valid in C/C++ but invalid in DM. I guarantee that new users will encounter this even more often. If the compiler were to assign the value to the expression, then it had better at least output a warning for cases like this.
I agree with your first suggestion, but it's more-or-less just a luxury-item so we can't make it much of a priority at the moment, unless it's something Dan can pull off in his sleep.
Plus, Deadron will have your head for expressions like this:
return initial((istype(t,/turf/area)?(t.loc):(t)).icon)
:)
P.S. I may not have mentioned this, Pmikell, but you don't need to use XMP on these forums just to enter code. It should preserve the indentation for you. That might save you some hassle!