The discussion seems to have settled now; leaving at least two groups of well founded but contrary opinions.

Because this is not a question of syntax but of semantics, I consider it a useful case for introducing a pragma that controls the behaviour of the compiler.

Because the introduction of pragmas, which control compiler behaviour, leads to a split of the programming community into different behaviours each version must be able to be automatically converted into the other.

Without such a conversion requirement the community is separated leaving at least two isles of coders and even worse, leaving at least two isles of modules or even systems, that can not be easily integrated: a nightmare for large projects, which would force the management to restrict the coders to one of the alternatives.

The management may want to have the system to follow a specific style. This may be induced by maintenance issues. As mentioned earlier, this imposes the requirement of a central automatically included policy, so that in the whole system there is only one instance of a pragma, that controls the behaviour of the compiler.

Note that this is not a contradiction to individual coding styles, because the parts of the system that are needed by the particular coder can be automatically converted to the style the coder uses.

Because no tools for automatically converting exist, the first step is to enable their making by adding a compiler option, that outputs the needed information: in this case a list of implicitly included narrowing conversions.

This output would be also an interim solution to that group that follows the more restrictive style.

So long.

Manfred Nowak wrote:

>The discussion seems to have settled now; leaving at least two groups of well founded but contrary opinions.
>
>Because this is not a question of syntax but of semantics, I consider it a useful case for introducing a pragma that controls the behaviour of the compiler.
>  
>
Sounds like another form of compiler switch, except it is in-code.  I don't like this idea because it means that coders will need to look at the extra pragmas as well.  When supplying example code, the pragmas will also need to be given.  Having to deal with cross-platform issues is bad enough, these pragmas would simply offer another level of complexity.  It would also divide the community into several camps as the warnings issue has in C++.

>This output would be also an interim solution to that group that follows the more restrictive style.
>
It could be useful as an interm solution but then again at least D 1.0 should start as a clean slate without all these on and off buttons.  One thing that could be useful in D 2.0 is a pragma that allows coders to use 1.0 code.  This way you have complete backwards support without spoiling any forward support functionality.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Sounds like another form of compiler switch, except it is in-code.

I have not tried, whether the current compiler switches may have different settings for different modules and the seperately compiled modules still produce a well functioning system, when linked together. If this is true, then the proposed usage of that pragma is different because there is only one possible setting for all modules in the system.

[...]
> these pragmas would simply offer another level of complexity.

That is surely true. Every alternative increases entropy. But every alternative increases also the usability of a system, iff it increases the adaptability of the system.

> It would also divide the community into several camps as the warnings issue has in C++.

Diversion of thinking and expression of that thinking is not a bad thing per se, iff the diversions are (re)unitable --- as I proposed. Disallowing a "camp" must therefore supply arguments to suppress it. Such an argument might very well be stated in holding up the status quo or that the evolving "camp" is currently of minor importance, where importance is measured in the number of inhabitants of that "camp". A vote is therefore nothing more than flagging to be an inhabitant of a particular "camp".

So you voted "for explicit casting" because "The programmer needs to explicitly mention his intentions.", i.e. repeat his intention at several places distributed over the code. Now you vote _against_ forcing the programmer to explicitely mention his intentions via a pragma at a central place. As long as you have not contributed any evidence for me being wrong, I will consider this inconsistent. Is there any reason to make inconsistent behaviour the base of a decision?

[...]

So long.

Manfred Nowak wrote:

>J Anderson wrote:
>  
>
>>Sounds like another form of compiler switch, except it is in-code.
>>    
>>
>
>I have not tried, whether the current compiler switches may have different
>settings for different modules and the seperately compiled modules still
>produce a well functioning system, when linked together. If this is true,
>then the proposed usage of that pragma is different because there is only
>one possible setting for all modules in the system.
>
>  
>
Walter hates adding switches for things like language changes and for good reason.

>[...]
>  
>
>>these pragmas would simply offer another level of complexity.
>>    
>>
>
>That is surely true. Every alternative increases entropy. But every
>alternative increases also the usability of a system, iff it increases the
>adaptability of the system.
>  
>
>>It would also divide the community into several camps as the warnings
>>issue has in C++.
>>    
>>
>
>Diversion of thinking and expression of that thinking is not a bad thing
>per se, iff the diversions are (re)unitable --- as I proposed. Disallowing
>a "camp" must therefore supply arguments to suppress it. Such an argument
>might very well be stated in holding up the status quo or that the
>evolving "camp" is currently of minor importance, where importance is
>measured in the number of inhabitants of that "camp". A vote is therefore
>nothing more than flagging to be an inhabitant of a particular "camp".
>  
>
>So you voted "for explicit casting" because "The programmer needs to
>explicitly mention his intentions.", i.e. repeat his intention at several
>places distributed over the code. Now you vote _against_ forcing the
>programmer to explicitely mention his intentions via a pragma at a central
>place. As long as you have not contributed any evidence for me being
>wrong, I will consider this inconsistent. Is there any reason to make
>inconsistent behaviour the base of a decision?
>  
>
You could have a point (for narrowing at least), although I'd suggest it would be a bad idea to do it at module level (even though it would have to be made possible.  I guess you could use pragmas in code like narrow ie:

void foo()
{
int a, b;
char c;

pragma (Narrow)
{
i = c + b;
}
}

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

[...]
> Walter hates adding switches for things like language changes and for good reason.

To hate something is a personal attitude and should be kept private. Good reasons should be made public.

[...]
> although I'd suggest it would be a bad idea to do it at module level

What are the arguments? I want you and Walter to explain, why the effect of pragmas should be so local.

And I believe, that if Walter will decide to keep up the current C-compatible narrowing as a standard and provide a "NoNarrow"-pragma, then you will find good reasons to have the effect of such a pragma be made module- or even system-wide.

However, belonging to different "camps", we have agreed on a unifying approach. This is of value per se.

So long.