6 ms·

Just some thoughts: #run can run anything, if you don't trust the codebase you have to check everything for malicious calls. ( #run format c: as a joke :-/ whe

Just some thoughts: #run can run anything, if you don't trust the codebase you have to check everything for malicious calls. ( #run format c: as a joke :-/ when you compile ) check functions seem to have limited use. They can't check for input that isn't hardcoded( or can they? ). A runtime check might be more valuable. I don't remember if it was mentioned; I think having C like implicit conversions is a bad idea. If types don't match exactly, cast or give an error. defer is interesting, do you get an error if you try to return an object which is also defered getting deleted?

krig 12y ago
Maybe the word check is a bit confusing, but the purpose of the feature is compile-time checking. Runtime checks would be implemented differently. To clarify the probable mindset of the language designer: For games, runtime checks are pretty much useless - at runtime, the game is released and it's too late to do anything (ideally, discounting patches). So you want to catch everything you can at compile time. At the same time, performance is crucial. You need to be able to do everything the game needs to do within a 16ms time window. This means hardcoding / compiling in as many calculations as possible. Hence the focus on being able to do a lot at compile time.
coffeeaddicted 12y ago
About the trust thing - you probably don't often compile code without running it afterwards even now. A format call might be hidden in any library you use.
- readerrrr 12y ago
  You are right. I usually wouldn't check the code if it is from a credible source anyway. That was just the first reaction I got, wow this can run anything.
lobster_johnson 12y ago
> #run can run anything, if you don't trust the codebase you have to check everything for malicious calls. That weakness already exists today in any project that relies on a build system (GNU Make, Autoconf, Ant/Maven, whatever), which is pretty much most of them.

krig 12y ago

Maybe the word check is a bit confusing, but the purpose of the feature is compile-time checking. Runtime checks would be implemented differently. To clarify the probable mindset of the language designer: For games, runtime checks are pretty much useless - at runtime, the game is released and it's too late to do anything (ideally, discounting patches). So you want to catch everything you can at compile time. At the same time, performance is crucial. You need to be able to do everything the game needs to do within a 16ms time window. This means hardcoding / compiling in as many calculations as possible. Hence the focus on being able to do a lot at compile time.

coffeeaddicted 12y ago

About the trust thing - you probably don't often compile code without running it afterwards even now. A format call might be hidden in any library you use.

readerrrr 12y ago
You are right. I usually wouldn't check the code if it is from a credible source anyway. That was just the first reaction I got, wow this can run anything.

lobster_johnson 12y ago

> #run can run anything, if you don't trust the codebase you have to check everything for malicious calls. That weakness already exists today in any project that relies on a build system (GNU Make, Autoconf, Ant/Maven, whatever), which is pretty much most of them.