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.
  


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/
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.

  


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/
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