January 21, 2012
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.
January 21, 2012
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
January 21, 2012
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
January 21, 2012
On 21 January 2012 22:18, Timon Gehr <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.
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.


January 22, 2012
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
January 22, 2012
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
January 22, 2012
sizediff_t or ptrdiff_t I think
January 22, 2012
"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.


January 22, 2012
"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...)


January 22, 2012
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