This list is for developers contributing to the C2 Language Specification or its Standard Library. The list can be high volume and sometimes quite technical. All decisions related to C2 Language Specification or its Standard Library are discussed here. Formal language or library proposals should also be submitted to this mailing list.

Re: Proposal for Include files/headers

edA-qa wrote:

> Rather than use the old C style of just #include I would recommend a 
> better manner of handling dependencies.

I agree that a more robust mechanism would be a good change. Let's see 
if we can come up with something useful...

> What would be nice is a Java style import system, which makes it easier 
> for new users, and can remove the problem of ordering of dependencies. 

We have to be very careful in trying to adopt something like the Java 
"import" model. The Java approach is very suitable for systems that use 
intermediate language representation (such as byte-codes). In those 
systems, declaration (header) files and implementation files are blended 
into one. But let's be ignorant for a while...

> (The #include system should also remain since it has other uses than 
> resolving dependencies).

I agree that the preprocessing phase is handy. Some enhancements to the 
preprocessor, such as support for recursion, would be useful-- 
generation of boiler plate templates with N-number of parameters would 
be a snap.

> Example:
> 
>     #import Math.Matrix    //get a single definition
>     #import Http    //get entire namespace

(Continue reading)

headers

edA-qa | 6 Sep 08:45

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> I suggest, rather than introducing another keyword, to enhance the 
> workings of the existing "using" language declaration. Also, I'm not 
> particularly fond of the idea that a program source code relies that 
> there is even a file-system underneath it. After all, classes, 

I don't like the idea of being file system dependent either.  Though in 
interests of portability you need to define at least one mechanism that 
users of the language have that *must* be provided by all implementations.

Also note that C++ doesn't say the <> system includes need to be files, 
an implementation is also free there to magically define everything they 
should include.

> A separate resource would provide necessary mapping information; a naive 
> example in XML:

Uggh, the world of XML comes to make something simple extremely robust. 
  Since, for the most part, people will be using files to define 
namespaces and classes, I suggest a simpler format which must be 
supported by default:

	namespace MySpace = file( "dir/dir/file.h2" ) {
		class MyClass = file( "dir/dir/file.h2" );
	}

This follows a similar syntax to the language itself so it won't be 
foreign to the programmers.  It also is very flexible and allows room 
for expansion.  It additioanlly paves the way to reflection in the 
language itself... :)

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 17:26

Re: Proposal for Include files/headers

edA-qa wrote:
> Uggh, the world of XML comes to make something simple extremely robust. 
>  Since, for the most part, people will be using files to define 
> namespaces and classes, I suggest a simpler format which must be 
> supported by default:
> 
>     namespace MySpace = file( "dir/dir/file.h2" ) {
>         class MyClass = file( "dir/dir/file.h2" );
>     }
> 

Indeed, the above is far more readable.

> Here is where my intent differed from users.  I do not intend for 
> "import" to move things out of their namespace, that would cause the 
> same sort of name clashes that exist in Java.
> 
> What you are proposing is that "using" does both the "import" and the 
> "using" directive. While this may be convenient it has many pitfalls 
> for name clashes, consider first in my syntax:

Let me clarify. One could use qualified names, in which case "using" 
could be omitted and name clashes prevented. In other words, you don't 
need to write "using" if you plan on explicitly qualifying a type.

Also, I opt for importing namespaces and not individual classes because 
we *want* to pull any free functions, such as operator+, defined for 
those classes.  In order to make it safe and efficient, we would have to 
go away from the existing C++ practice, where, for example, an entire 
std. library is in one namespace. A given bottom-level namespace would

(Continue reading)

headers

edA-qa | 6 Sep 18:03

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> Let me clarify. One could use qualified names, in which case "using" 
> could be omitted and name clashes prevented. In other words, you don't 
> need to write "using" if you plan on explicitly qualifying a type.

Your explanation, not just the above, is omitting one of the common uses 
of the using directive: to import a set of names, not just a single 
object, where further names will be half-qualified, or not qualified.

Consider:

using Architecture.Car;
Door left,right;
...
using Architecture.House;
Door front, back;
...
using Architecture;
Car::Door left, right;
House::Door front, back;

> Also, I opt for importing namespaces and not individual classes because 
> we *want* to pull any free functions, such as operator+, defined for 
> those classes.  In order to make it safe and efficient, we would have to 
> go away from the existing C++ practice, where, for example, an entire 
> std. library is in one namespace. A given bottom-level namespace would 
> have a single type (primary) and any free functions defined for it. Here 
> is a String type written in this fashion:

I've recently read such sections in C++ about free functions on classes.

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 19:26

Re: Proposal for Include files/headers

edA-qa wrote:
> I've recently read such sections in C++ about free functions on classes. 
>  The search-space for functions occurs within the namespace of those 
> classes as well as the local scope.  The lookup is not simple, but in 
> order to use the String+ operator you do not need to include it in the 
> local namespace.

I think the existing C++ lookup rules are very criptic and not as safe 
as many people assume. Yes, the operator+ is visible without "using", 
but there are plenty of other issues to worry about. Some of them are 
described here: http://boost-consulting.com/writing/qn.html

> Having to import the entire namespace becomes messy, and as you've shown 
> in your example just before, you'd have to separate out every single 
> aspect into sub-namespaces.

I think it would serve the purpose of encapsulation and logical grouping 
(examples later). I would also restrict default rules where 
argument-dependent lookup does not take effect for arbitrary unqualified 
calls.

> Then you need to introduce a "this_namespace" namespace in order to 
> resolve ambiguities.  Example:
> 
> namepsace Math {
> 
> class Complex;
> class Matrix;
> 
> }

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 23:12

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:

> For clarity, I would recommend that types like Integer, Float and Matrix 
> above be in separate files. The rotate function would then be:
> 
> namespace Math
> {
>   namespace Algorithm
>   {
>     Math.Matrix rotate( Math.Matrix mat, Math.Float deg );
> 
>     // other common algorithms here...
>   }
> }
> 

Actually, since Algorithm, Matrix and Float share common parent 
namespace, it would be even simpler than my example:

namespace Math
{
   namespace Algorithm
   {
     Matrix rotate( Matrix mat, Float deg );

     // other common algorithms here...
   }
}

Now, let's assume that the user decided to add a type within an inner

(Continue reading)

headers

edA-qa | 7 Sep 17:59

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> The problem above is that class Matrix in Math.Algorithm clashes with 
> Matrix (primary) in an enclosing namespace Math. What now? Well, in my 
> opinion this is a bad design and compiler should complain. Users 
> shouldn't be allowed nesting namespaces and re-define outer 
> classes/namespaces within inner namespaces. C++ is less strict today. In 
> general, I'd rather have an annoying language than unsafe-- of course 
> within reason.

Clashing names don't tend to happen by way of design, they come about 
through using various libraries and maintaing your own library over time.

In the case of a math library, perhaps Matrix wasn't defined before 
since it wasn't used at the global level, but in one of the 
sub-namespaces, for Algorithms, one programmer defined a simple Matrix 
for his use.

Later on in the project somebody realizes they need a global Matrix, so 
he defines it in the outer namespace.  Does it make sense that providing 
this outer definition then suddenly makes the inner code no longer work?

There is also very good reason to allow libary users to nest namespaces, 
it is a point that Java has failed very poorly on (I'm going through 
this in my work now): libraries should encapsulate their entire 
infrastructure and support system in order to prevent version clashes 
and lookup problems.

That is to say, in projects it is sometimes good to use an #Include 
statement inside your own namespace in order to completely isolate any 
symbols I may need.  This allows me to treat the library as truly an

(Continue reading)

headers

Slawomir Lisznianski | 8 Sep 03:45

Re: Proposal for Include files/headers

edA-qa wrote:
> Later on in the project somebody realizes they need a global Matrix, so 
> he defines it in the outer namespace.  Does it make sense that providing 
> this outer definition then suddenly makes the inner code no longer work?

It's impossible to answer this question without practical context. My 
first impression is that having two Matrix classes under the same hood 
(some higher-level namespace) is generally a bad idea.

> That is to say, in projects it is sometimes good to use an #Include 
> statement inside your own namespace in order to completely isolate any 
> symbols I may need. 

Only header-contained libraries, such as STL, can be nested this way. 
Symbols exported from objects have "original" namespaces mangled in.

> This allows me to treat the library as truly an 
> isolated component -- whereas if somehow it was polluting a common 
> namespace I would have problems.

As explained, in practice, the scope of repackaging is limited to 
template libraries.

   I think we're slowly swinging away from any potential solution, 
which, admittedly, is not clear to me right now. At this point, we have 
just about two options. One, we can leave it as is, and not worry about 
it for the time being-- as Rajesh suggested in his post. Two, try to 
come up with a list of things that we agree on or consider essential and 
then try again. I can start with a few, feel free to add/remove:

(Continue reading)

headers

edA-qa | 7 Sep 17:48

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> I think the existing C++ lookup rules are very criptic and not as safe 
> as many people assume. Yes, the operator+ is visible without "using", 
> but there are plenty of other issues to worry about. Some of them are 
> described here: http://boost-consulting.com/writing/qn.html

Agreed: C++ rules are not clear and lead to very interesting situations. 
  That does not however mean we should abandon some kind of contextual 
name lookup.

>   Math.Complex a, b; // primary deduced from namespace name

This I consider too bulky.  Plus I can give an example below of why it 
doesn't work.

>   class Matrix<Math.Matrix>;

I used this as an example to show resolution in *odd* cases of overlap.

> C++ spec-- admittedly at the cost of being explicit when referring to 
> types.

namespace Precise {
	class Complex;
	class Integer;
}
namespace Rough {
	class Complex;
	class Integer;
}

(Continue reading)