www.digitalmars.com         C & C++   DMDScript  

D - [Unifying approach] Implicit narrowing conversions

reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Mar 06 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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.
  

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.

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/
Mar 07 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Mar 07 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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.

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?

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/
Mar 07 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
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.
Mar 08 2004