Walter's second axiom

Jason House jason.james.house at gmail.com
Wed Dec 12 08:46:49 PST 2007


Derek Parnell Wrote:

> On Tue, 11 Dec 2007 18:57:17 -0500, Jason House wrote:
> 
> > Walter Bright wrote:
> >> That axiom didn't really exist until Andrei started pointing out to me
> >> all the advantages of being able to wrap types in a struct. So we can
> >> expect some historical problems with it.
> > 
> > Can you please share with us all the advantages of "Any type T can be
> > wrapped inside a struct S, and that S can be made to behave as a typedef
> > for type T."
> > 
> > Under what conditions can it behave exactly like a typedef?  If it behaves
> > *exactly* as a typedef under all circumstances, then it can't have any
> > additional data members or member functions and must behave exactly like
> > the original.  If that's true, why wrap it in a struct at all?
> 
> I don't think that Walter was suggesting that one actually does this ...
> 
>   struct LONG { long x; }
>   LONG foo;
> 
> because that would be a bit pointless, and because it would also show that
> you need to use different syntax when using structs rather than typedefs
> ...

That still leaves me wondering what he's suggesting that we do, and how it fits into expanding generic programming support.  It seems like this mailing list has a lot of trouble convincing Walter of our viewpoints.  Somehow, Andrei has succeeded and I have to assume that there were a number of good arguments and motivating examples.

I'd also expect axioms to be well worded and iron-clad concepts.  They are after-all, an acid test for addition of features.  If the goal is really an ability to define a new type that can be used in a similar way to another type (including application of const), I think that's a lot different than wrapping in a struct and a lot different than defining a typedef.

As I understand the const/tail-const problems, I think that char[], const(char) [], and const char[] are three distinct types.  Using a reference struct of struct foo{ char[] x}, the middle array type (tail const) is impossible to achieve with a simple application of const to the type...  foo and const foo are well defined, but tail const makes little sense.

I'd like to provide better feedback in the const debate, but I need to really understand what the real goal is.

For example, arrays and associative arrays tend to pose a unique problem with axiom #2.  I've been trying to think of arrays and associative arrays as nothing special... array!(T) and AA!(T) instead of specialized syntax.  Looking at normal arrays, the three const types would translate to array!(char), array!(const(char)), const array!(char).  In that form, tail const really has a different feel...  If we have templated structs in a similar way, it may be a good way to think about this issue... I just don't know yet.



More information about the Digitalmars-d mailing list