www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - isize_t?

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
Hi,

I needed a native-size signed integer type this other day and was just 
kinda wondering: Why don't we have this in object.di? isize_t or whatever?

(I have a feeling this has been asked before, but my search-fu is weak 
today seemingly...)

-- 
- Alex
Jan 21 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:

 Hi,

 I needed a native-size signed integer type this other day and was just
 kinda wondering: Why don't we have this in object.di? isize_t or whatever?

 (I have a feeling this has been asked before, but my search-fu is weak
 today seemingly...)


.object.ptrdiff_t
Jan 21 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 21-01-2012 21:18, Timon Gehr wrote:

 On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:

 Hi,

 I needed a native-size signed integer type this other day and was just
 kinda wondering: Why don't we have this in object.di? isize_t or
 whatever?

 (I have a feeling this has been asked before, but my search-fu is weak
 today seemingly...)


 .object.ptrdiff_t


While it does what I want, it's not exactly ideal. I just want a 
general-purpose native-size signed integer. ptrdiff_t sounds like it 
must have something to do with pointers, which is not what I want my API 
to look like. I could alias ptrdiff_t to isize_t, but then that defeats 
the purpose right there. Do you think that it would be a big deal to add 
an alias ptrdiff_t isize_t; to object.di?

-- 
- Alex
Jan 21 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
There's sizediff_t which is the same thing.
Jan 21 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 21-01-2012 22:46, Andrej Mitrovic wrote:

 There's sizediff_t which is the same thing.


I still think this type name has some specific notion to it. "isize_t" 
alone just means "a signed integer the size of a pointer" (same for 
size_t, minus the signed), while sizediff_t means something along the 
lines of "an integer the size of the result of an arithmetic operation 
on a pointer".

-- 
- Alex
Jan 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jffbuc$2b37$1 digitalmars.com...

 On 21-01-2012 22:46, Andrej Mitrovic wrote:

 There's sizediff_t which is the same thing.


 I still think this type name has some specific notion to it. "isize_t" 
 alone just means "a signed integer the size of a pointer" (same for 
 size_t, minus the signed), while sizediff_t means something along the 
 lines of "an integer the size of the result of an arithmetic operation on 
 a pointer".


The names of "ptrdiff_t" and "size_t" *are* terrible, but that's what we 
have. There was a big thread not too long ago about getting better names, 
even just as standard alternatives, but the powers that be just weren't 
interested. So if we want sensible names for them, we have to make up 
non-standardized aliases in each individual project. :/
Jan 21 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
There are some more ints here, ints for everyone, for people with long or short
feet or no feet:
http://www.dlang.org/phobos/std_stdint.html

Bye,
bearophile
Jan 21 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 21-01-2012 22:59, bearophile wrote:

 There are some more ints here, ints for everyone, for people with long or
short feet or no feet:
 http://www.dlang.org/phobos/std_stdint.html

 Bye,
 bearophile


Hm, might just end up using those.

-- 
- Alex
Jan 21 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
This has been discussed before on this NG (I don't have the links to
the discussions, sorry!) but additional aliases will not be added.
You'll have to use what you have or introduce your own aliases in your
code.
Jan 21 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 21-01-2012 23:01, Andrej Mitrovic wrote:

 This has been discussed before on this NG (I don't have the links to
 the discussions, sorry!) but additional aliases will not be added.
 You'll have to use what you have or introduce your own aliases in your
 code.


Le sigh. Consistent, standardized names would have been really nice.

-- 
- Alex
Jan 21 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 21, 2012 23:07:17 Alex R=C3=B8nne Petersen wrote:

 On 21-01-2012 23:01, Andrej Mitrovic wrote:

 This has been discussed before on this NG (I don't have the links t=




o

 the discussions, sorry!) but additional aliases will not be added.
 You'll have to use what you have or introduce your own aliases in y=




our

 code.


=20
 Le sigh. Consistent, standardized names would have been really nice.


size_t comes from C/C++, and is exactly the same as it is in C++. In D,=
 you=20
know that if a type ends in _t, then its size can vary depending on the=
=20
machine that you compile on, unlike all of the other primitive types.

Maybe another name would have been better, but it works, and I think th=
at most=20
people who have been C/C++ programmers just don't care. The know size_t=
, and=20
it works.

At this point, given how much code would break from changing it, you wo=
uld=20
have to demonstrate that whatever name you came up with was really wort=
h that=20
cost, I realyl don't think that that's going to happen.

- Jonathan M Davis
Jan 21 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.671.1327197702.16222.digitalmars-d puremagic.com...

size_t comes from C/C++, and is exactly the same as it is in C++. In D, you
know that if a type ends in _t, then its size can vary depending on the
machine that you compile on, unlike all of the other primitive types.

Maybe another name would have been better, but it works, and I think that 
most
people who have been C/C++ programmers just don't care. The know size_t, 
and
it works.

At this point, given how much code would break from changing it, you would
have to demonstrate that whatever name you came up with was really worth 
that
cost, I realyl don't think that that's going to happen.


It wouldn't have to change, just have a better name added. No reason 
'size_t', et al, couldn't still be kept for compatibility.
Jan 21 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:

 It wouldn't have to change, just have a better name added. No reason
 'size_t', et al, couldn't still be kept for compatibility.


Except that we're generally against keeping around alias cruft like that 
except temporarily as part of a deprecation path, so that doesn't usually fly. 
Certainly, it means that if you want that to happen, you'd then have to be 
able to come up with a name and arguments for it which justified having two 
standard aliases for the same thing.

- Jonathan M Davis
Jan 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.674.1327201445.16222.digitalmars-d puremagic.com...

 On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:

 It wouldn't have to change, just have a better name added. No reason
 'size_t', et al, couldn't still be kept for compatibility.


 Except that we're generally against keeping around alias cruft like that
 except temporarily as part of a deprecation path, so that doesn't usually 
 fly.
 Certainly, it means that if you want that to happen, you'd then have to be
 able to come up with a name and arguments for it which justified having 
 two
 standard aliases for the same thing.


How about: "Because the existing ones blow and removing them outright is 
never gonna happen"? ;)
Jan 21 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:

 It wouldn't have to change, just have a better name added. No reason
 'size_t', et al, couldn't still be kept for compatibility.


 Except that we're generally against keeping around alias cruft like that
 except temporarily as part of a deprecation path, so that doesn't usually fly.
 Certainly, it means that if you want that to happen, you'd then have to be
 able to come up with a name and arguments for it which justified having two
 standard aliases for the same thing.


I agree with Jonathan. Two names for the same thing just blows.
Jan 21 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfg0p4$i1j$1 digitalmars.com...

 On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:

 It wouldn't have to change, just have a better name added. No reason
 'size_t', et al, couldn't still be kept for compatibility.


 Except that we're generally against keeping around alias cruft like that
 except temporarily as part of a deprecation path, so that doesn't usually 
 fly.
 Certainly, it means that if you want that to happen, you'd then have to 
 be
 able to come up with a name and arguments for it which justified having 
 two
 standard aliases for the same thing.


 I agree with Jonathan. Two names for the same thing just blows.


Sure it blows, but not as much as sticking to god-awful names like ptrdiff_t 
and size_t.

And yea, you could label it a bikeshedding issue, but really...There's 
questionable bikeshed colors, and then there's "lime green with orange 
stripes and pink polka dots, all largely obscured by a giant shit stain and 
three rotting rat carcasses."
Jan 21 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2012 05:51, Nick Sabalausky <a a.a> wrote:


 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:jfg0p4$i1j$1 digitalmars.com...

 On 1/21/2012 7:03 PM, Jonathan M Davis wrote:

 On Saturday, January 21, 2012 21:54:37 Nick Sabalausky wrote:

 It wouldn't have to change, just have a better name added. No reason
 'size_t', et al, couldn't still be kept for compatibility.


 Except that we're generally against keeping around alias cruft like that
 except temporarily as part of a deprecation path, so that doesn't




 usually

 fly.
 Certainly, it means that if you want that to happen, you'd then have to
 be
 able to come up with a name and arguments for it which justified having
 two
 standard aliases for the same thing.


 I agree with Jonathan. Two names for the same thing just blows.


 Sure it blows, but not as much as sticking to god-awful names like
 ptrdiff_t
 and size_t.

 And yea, you could label it a bikeshedding issue, but really...There's
 questionable bikeshed colors, and then there's "lime green with orange
 stripes and pink polka dots, all largely obscured by a giant shit stain and
 three rotting rat carcasses."


Also size_t and ptrdiff_t are not necessarily the same size.
Is there a signed size_t type? Is there an unsigned ptrdiff_t type? What
are they?
Jan 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.688.1327228280.16222.digitalmars-d puremagic.com...

 Also size_t and ptrdiff_t are not necessarily the same size.


Hah! That's going to be LOADS of fun when I encounter it!!

Ugh...
Jan 22 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 22, 2012, at 2:30 AM, Manu wrote:

=20
 Also size_t and ptrdiff_t are not necessarily the same size.
 Is there a signed size_t type? Is there an unsigned ptrdiff_t type? =


What are they?

There's ssize_t in the Posix world.  ptrdiff_t is the closes you can get =
in C99 though, I believe.
Jan 23 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 22-01-2012 03:00, Jonathan M Davis wrote:

 On Saturday, January 21, 2012 23:07:17 Alex Rønne Petersen wrote:

 On 21-01-2012 23:01, Andrej Mitrovic wrote:

 This has been discussed before on this NG (I don't have the links to
 the discussions, sorry!) but additional aliases will not be added.
 You'll have to use what you have or introduce your own aliases in your
 code.


 Le sigh. Consistent, standardized names would have been really nice.


 size_t comes from C/C++, and is exactly the same as it is in C++. In D, you
 know that if a type ends in _t, then its size can vary depending on the
 machine that you compile on, unlike all of the other primitive types.

 Maybe another name would have been better, but it works, and I think that most
 people who have been C/C++ programmers just don't care. The know size_t, and
 it works.

 At this point, given how much code would break from changing it, you would
 have to demonstrate that whatever name you came up with was really worth that
 cost, I realyl don't think that that's going to happen.

 - Jonathan M Davis


I wasn't suggesting changing size_t, but rather ptrdiff_t which is much 
less commonly used. (Or alternatively, just adding a ptrdiff_t -> 
isize_t alias.)

-- 
- Alex
Jan 22 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 12:25:25 Alex R=C3=B8nne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is mu=


ch

 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)


What you want is probably ssize_t. It's only defined for Posix at the m=
oment=20
though (core.sys.posix.sys.types).

- Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 03:41:30 Jonathan M Davis wrote:

 On Sunday, January 22, 2012 12:25:25 Alex R=C3=B8nne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is =




much

 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)


=20
 What you want is probably ssize_t. It's only defined for Posix at the=


 moment

 though (core.sys.posix.sys.types).


Actually, a better idea would be to just use c_long (which is what ssiz=
e_t is=20
anyway), which is in core.stdc.config. It's available on all OSes.

- Jonathan M Davis
Jan 22 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 5:25 AM, Alex Rønne Petersen wrote:

 I wasn't suggesting changing size_t, but rather ptrdiff_t which is much
 less commonly used. (Or alternatively, just adding a ptrdiff_t ->
 isize_t alias.)


Check .object.sizediff_t.

Andrei
Jan 22 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 21 January 2012 22:18, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 01/21/2012 09:06 PM, Alex R=C3=B8nne Petersen wrote:


 Hi,

 I needed a native-size signed integer type this other day and was just
 kinda wondering: Why don't we have this in object.di? isize_t or whateve=




r?

 (I have a feeling this has been asked before, but my search-fu is weak
 today seemingly...)


 .object.ptrdiff_t


I don't necessarily think ptrdiff_t and signed size_t are the same thing.
Surely size_t should represent the systems native word width? ptrdiff_t
represents the size of a pointer, which is NOT necessarily the same as the
native word width.
There are quite a few 64 bit systems that retain 32bit pointers. I would
thing ssize_t is safer than using ptrdiff_t, and certainly, both should
exist.
Jan 21 2012
parent reply Don Clugston <dac nospam.com> writes:
On 22/01/12 00:15, Manu wrote:

 On 21 January 2012 22:18, Timon Gehr <timon.gehr gmx.ch
 <mailto:timon.gehr gmx.ch>> wrote:

     On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:

         Hi,

         I needed a native-size signed integer type this other day and
         was just
         kinda wondering: Why don't we have this in object.di? isize_t or
         whatever?

         (I have a feeling this has been asked before, but my search-fu
         is weak
         today seemingly...)


     .object.ptrdiff_t


 I don't necessarily think ptrdiff_t and signed size_t are the same thing.
 Surely size_t should represent the systems native word width? ptrdiff_t
 represents the size of a pointer, which is NOT necessarily the same as
 the native word width.


Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee 
a flat address space?
I mean, back in the old 16 bit segmented architecture days, you could 
have two 32 bit pointers p and q, and have the difference between them 
being 16 bits (or an error, if the segments were different).

Maybe similar oddities are possible on the less traditional 
architectures (Cell, maybe?)


 There are quite a few 64 bit systems that retain 32bit pointers. I would
 thing ssize_t is safer than using ptrdiff_t, and certainly, both should
 exist.
Jan 23 2012
parent Manu <turkeyman gmail.com> writes:
On 23 January 2012 12:55, Don Clugston <dac nospam.com> wrote:


 On 22/01/12 00:15, Manu wrote:


 On 21 January 2012 22:18, Timon Gehr <timon.gehr gmx.ch
 <mailto:timon.gehr gmx.ch>> wrote:

    On 01/21/2012 09:06 PM, Alex R=C3=B8nne Petersen wrote:

        Hi,

        I needed a native-size signed integer type this other day and
        was just
        kinda wondering: Why don't we have this in object.di? isize_t or
        whatever?

        (I have a feeling this has been asked before, but my search-fu
        is weak
        today seemingly...)


    .object.ptrdiff_t


 I don't necessarily think ptrdiff_t and signed size_t are the same thing=




.

 Surely size_t should represent the systems native word width? ptrdiff_t
 represents the size of a pointer, which is NOT necessarily the same as
 the native word width.


 Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee a
 flat address space?
 I mean, back in the old 16 bit segmented architecture days, you could hav=


e

 two 32 bit pointers p and q, and have the difference between them being 1=


6

 bits (or an error, if the segments were different).

 Maybe similar oddities are possible on the less traditional architectures
 (Cell, maybe?)



Cell is too weird to worry about (just treat it as 32bit), but it's fairly
common to have embedded systems with 64bit processors which retain 32bit
pointers because the memory map is fixed, and there's no point. All games
consoles, perhaps even phones with the new 64bit ARM processors. Phones
don't need >4gb of ram ;) .. Should size_t on this device be 32 or 64bits?
The pointers and OS will still be 32bits, I don't see them releasing an
Android-64 any time soon.
Jan 23 2012
prev sibling next sibling parent reply equinox atw.hu writes:
Hi,

I have an import related questoin..

I have this:

module A;

const c1=4;


module B;

import A;


module C;

private import B;



Should not module C see c1? Because it cannot see it. Even if the import  
is not private.




Regards


Marton Papp
Jan 21 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 21, 2012 21:22:22 equinox atw.hu wrote:

 Hi,
 
 I have an import related questoin..
 
 I have this:
 
 module A;
 
 const c1=4;
 
 
 module B;
 
 import A;
 
 
 module C;
 
 private import B;
 
 
 
 Should not module C see c1? Because it cannot see it. Even if the import
 is not private.


No. imports are private by default There's no point in marking them as 
private. If you want module C to see what module B is importing, then module B 
needs to import it publicly. e.g.

module B;

public import A;

- Jonathan M Davis
Jan 21 2012
parent reply equinox atw.hu writes:
 Should not module C see c1? Because it cannot see it. Even if the import
 is not private.


 No. imports are private by default There's no point in marking them as
 private. If you want module C to see what module B is importing, then  
 module B
 needs to import it publicly. e.g.

 module B;

 public import A;

 - Jonathan M Davis



It makes sense. But did it always work like this?



Marton Papp
Jan 21 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 21, 2012 22:28:20 equinox atw.hu wrote:

 Should not module C see c1? Because it cannot see it. Even if the
 import
 is not private.


 
 No. imports are private by default There's no point in marking them as
 private. If you want module C to see what module B is importing, then
 module B
 needs to import it publicly. e.g.
 
 module B;
 
 public import A;
 
 - Jonathan M Davis


 
 It makes sense. But did it always work like this?


It has for several years at minimum. But I don't know how it works in D1, and 
it may have worked differently in the very beginning of D2. I don't know. But 
as far as I know, it's always worked this way.

- Jonathan m Davis
Jan 21 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.670.1327197408.16222.digitalmars-d puremagic.com...

 On Saturday, January 21, 2012 22:28:20 equinox atw.hu wrote:

 Should not module C see c1? Because it cannot see it. Even if the
 import
 is not private.


 No. imports are private by default There's no point in marking them as
 private. If you want module C to see what module B is importing, then
 module B
 needs to import it publicly. e.g.

 module B;

 public import A;

 - Jonathan M Davis


 It makes sense. But did it always work like this?


 It has for several years at minimum. But I don't know how it works in D1, 
 and
 it may have worked differently in the very beginning of D2. I don't know. 
 But
 as far as I know, it's always worked this way.


I have a vague recollection of it being the other way around at one point, 
but that probably would have been pre-1.0. *Definitely* pre-2.0. (Or I might 
just be thinking of something else...)
Jan 21 2012
parent reply Don Clugston <dac nospam.com> writes:
On 22/01/12 03:56, Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.670.1327197408.16222.digitalmars-d puremagic.com...

 On Saturday, January 21, 2012 22:28:20 equinox atw.hu wrote:

 Should not module C see c1? Because it cannot see it. Even if the
 import
 is not private.


 No. imports are private by default There's no point in marking them as
 private. If you want module C to see what module B is importing, then
 module B
 needs to import it publicly. e.g.

 module B;

 public import A;

 - Jonathan M Davis


 It makes sense. But did it always work like this?


 It has for several years at minimum. But I don't know how it works in D1,
 and
 it may have worked differently in the very beginning of D2. I don't know.
 But
 as far as I know, it's always worked this way.


 I have a vague recollection of it being the other way around at one point,
 but that probably would have been pre-1.0. *Definitely* pre-2.0. (Or I might
 just be thinking of something else...)


Version D 0.163 Jul 18, 2006
New/Changed Features

     Imports now default to private instead of public. Breaks existing code.
     Added static imports, renamed imports, and selective importing.
Jan 23 2012
parent reply Manu <turkeyman gmail.com> writes:
On 23 January 2012 12:47, Don Clugston <dac nospam.com> wrote:


 On 22/01/12 03:56, Nick Sabalausky wrote:


 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.670.1327197408.**16222.digitalmars-d puremagic.**com...


 On Saturday, January 21, 2012 22:28:20 equinox atw.hu wrote:


 Should not module C see c1? Because it cannot see it. Even if the

 import
 is not private.


 No. imports are private by default There's no point in marking them as
 private. If you want module C to see what module B is importing, then
 module B
 needs to import it publicly. e.g.

 module B;

 public import A;

 - Jonathan M Davis


 It makes sense. But did it always work like this?


 It has for several years at minimum. But I don't know how it works in D1,
 and
 it may have worked differently in the very beginning of D2. I don't know.
 But
 as far as I know, it's always worked this way.


 I have a vague recollection of it being the other way around at one point,
 but that probably would have been pre-1.0. *Definitely* pre-2.0. (Or I
 might
 just be thinking of something else...)


 Version D 0.163 Jul 18, 2006
 New/Changed Features

    Imports now default to private instead of public. Breaks existing code.
    Added static imports, renamed imports, and selective importing


What is a static import? It sounds like something I might have needed last
night...
Jan 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2012 01:33 PM, Manu wrote:

 On 23 January 2012 12:47, Don Clugston <dac nospam.com
 <mailto:dac nospam.com>> wrote:

     On 22/01/12 03:56, Nick Sabalausky wrote:

         "Jonathan M Davis"<jmdavisProg gmx.com
         <mailto:jmdavisProg gmx.com>>  wrote in message
         news:mailman.670.1327197408.__16222.digitalmars-d puremagic.__com...

             On Saturday, January 21, 2012 22:28:20 equinox atw.hu
             <mailto:equinox atw.hu> wrote:

                         Should not module C see c1? Because it cannot
                         see it. Even if the
                         import
                         is not private.


                     No. imports are private by default There's no point
                     in marking them as
                     private. If you want module C to see what module B
                     is importing, then
                     module B
                     needs to import it publicly. e.g.

                     module B;

                     public import A;

                     - Jonathan M Davis


                 It makes sense. But did it always work like this?


             It has for several years at minimum. But I don't know how it
             works in D1,
             and
             it may have worked differently in the very beginning of D2.
             I don't know.
             But
             as far as I know, it's always worked this way.


         I have a vague recollection of it being the other way around at
         one point,
         but that probably would have been pre-1.0. *Definitely* pre-2.0.
         (Or I might
         just be thinking of something else...)


     Version D 0.163 Jul 18, 2006
     New/Changed Features

         Imports now default to private instead of public. Breaks
     existing code.
         Added static imports, renamed imports, and selective importing


 What is a static import? It sounds like something I might have needed
 last night...


A static import is an import that makes the module visible but does not 
import any of it's members into the current scope:

static import std.stdio;

void main(){
     // writeln("hello, world!");        // undefined symbol
     std.stdio.writeln("hello, world!"); // ok
}
Jan 25 2012
prev sibling parent Trass3r <un known.com> writes:
sizediff_t or ptrdiff_t I think
Jan 21 2012