Weed Wrote:

> >>>> too cannot be initialized in a compile time.
> >>> Sure it can't. Does it cause that big problems?
> >> Sometimes it is the only way to avoid a large number of global ad
> > 
> > In D module variables can be protected by access modifiers and become module-local.
> 
> Module full of mathematics turns into horror quite quickly. I have checked this:)

If you have troubles with understanding big modules, you can split them into smaller modules, which will be easier to understand for sure.

Kagamin пишет:
> Weed Wrote:
> 
>>>>>> too cannot be initialized in a compile time.
>>>>> Sure it can't. Does it cause that big problems?
>>>> Sometimes it is the only way to avoid a large number of global ad
>>> In D module variables can be protected by access modifiers and become module-local.
>> Module full of mathematics turns into horror quite quickly. I have checked this:)
> 
> If you have troubles with understanding big modules, you can split them into smaller modules, which will be easier to understand for sure.


If you do not want to initialize repeatedly matrix inside the sub, which often cause each other, must be static matrices or declared as global (in relation to these procedures). You agree with that?

Do you propose through mixin divide the code into parts?

You do not think that it is better to add to language that would give 100% to use the opportunity of calculations at compile time. This greatly simplify the code and perfectly and logically fit into the language.

Weed Wrote:

> If you do not want to initialize repeatedly matrix inside the sub, which often cause each other, must be static matrices or declared as global (in relation to these procedures). You agree with that?

What's problem? If you want static or global variables, you have them in D.

> Do you propose through mixin divide the code into parts?

Well, why mixin? Just create different modules and place code according to its purpose to these modules.

> You do not think that it is better to add to language that would give 100% to use the opportunity of calculations at compile time. This greatly simplify the code and perfectly and logically fit into the language.

Compile-time evaluation is just an optimization technique, which may or may not be applied without any change to source code, so it doesn't affect source code in any way, it just can't. In C++ you can't tell whether the code executes at compile time, as as of standard, it's completely up to the compiler to optimize code generation.

Kagamin пишет:
> Weed Wrote:
> 
>> If you do not want to initialize repeatedly matrix inside the sub, which often cause each other, must be static matrices or declared as global (in relation to these procedures). You agree with that?
> 
> What's problem? If you want static or global variables, you have them in D.
> 
>> Do you propose through mixin divide the code into parts?
> 
> Well, why mixin? Just create different modules and place code according to its purpose to these modules.
> 
>> You do not think that it is better to add to language that would give 100% to use the opportunity of calculations at compile time. This greatly simplify the code and perfectly and logically fit into the language.
> 
> Compile-time evaluation is just an optimization technique, which may or may not be applied without any change to source code, so it doesn't affect source code in any way, it just can't. In C++ you can't tell whether the code executes at compile time, as as of standard, it's completely up to the compiler to optimize code generation.

Yeah, right.

I propose that it be expanded to optimize the static arrays and classes.

Kagamin пишет:
> Weed Wrote:
> 
>> If you do not want to initialize repeatedly matrix inside the sub, which often cause each other, must be static matrices or declared as global (in relation to these procedures). You agree with that?
> 
> What's problem? If you want static or global variables, you have them in D.
> 
>> Do you propose through mixin divide the code into parts?
> 
> Well, why mixin? Just create different modules and place code according to its purpose to these modules.
> 
>> You do not think that it is better to add to language that would give 100% to use the opportunity of calculations at compile time. This greatly simplify the code and perfectly and logically fit into the language.
> 
> Compile-time evaluation is just an optimization technique, which may or may not be applied without any change to source code,

Incidentally, this is incorrect.

In the event that it is impossible to calculate the static expression compiler immediately gives an error rather than moves calculation to run-time.