"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"? ;)

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.

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

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?

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

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

On Sunday, January 22, 2012 12:25:25 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.)

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

- Jonathan M Davis

On Sunday, January 22, 2012 03:41:30 Jonathan M Davis wrote:
> On Sunday, January 22, 2012 12:25:25 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.)
> 
> 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 ssize_t is anyway), which is in core.stdc.config. It's available on all OSes.

- Jonathan M Davis

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

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.