January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | "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"? ;) |
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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.
|
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "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." |
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky Attachments:
| 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?
|
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | "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... |
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 |
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
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
|
January 22, 2012 Re: isize_t? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
January 23, 2012 Re: import question | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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.
|
Copyright © 1999-2021 by the D Language Foundation