The effect is the same. You have a new type with a new init, that behaves the same way.

On Sat, May 5, 2012 at 10:38 PM, Mehrdad <wfunction@hotmail.com> wrote:
> The one with TypeDef?
>
> That's not how it's defined though.
>
> On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:
>>
>> See my version.



-- 
Bye,
Gor Gyolchanyan.

Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are.

On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote:
> The effect is the same. You have a new type with a new init, that
> behaves the same way.
>
> On Sat, May 5, 2012 at 10:38 PM, Mehrdad <wfunction@hotmail.com> wrote:
>> The one with TypeDef?
>>
>> That's not how it's defined though.
>>
>> On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:
>>>
>>> See my version.

well, there's no solution to it of the alias is in use, no matter what alternatives are.

On Sat, May 5, 2012 at 10:43 PM, Mehrdad <wfunction@hotmail.com> wrote:
> Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are.
>
>
> On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote:
>>
>> The effect is the same. You have a new type with a new init, that behaves the same way.
>>
>> On Sat, May 5, 2012 at 10:38 PM, Mehrdad <wfunction@hotmail.com> wrote:
>>>
>>> The one with TypeDef?
>>>
>>> That's not how it's defined though.
>>>
>>> On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:
>>>>
>>>>
>>>> See my version.
>
>
>



-- 
Bye,
Gor Gyolchanyan.

One solution is to bring back typedef, at least for non-classes and non-interfaces.

Another is to change the definition of size_t.

Neither of which anyone except the compiler/library developers can fix.


On Saturday, 5 May 2012 at 18:52:57 UTC, Gor Gyolchanyan wrote:
> well, there's no solution to it of the alias is in use, no matter what
> alternatives are.

On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote:
> Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are.

Out of curiosity, why would you need to "know" which parameters
are size_t? True, size_t is either uint or ulong and you can't
really know for sure if you have a uint or ulong and it was
actually a size_t ... but why would you need to know?

That's *such* a lame question...

Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.

But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!

In other words, this must NOT compile!

auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(&test), size_t)(&test, 1); }

If you're still asking "why shouldn't it compile" then you should
look up what "type safety" means.


On Saturday, 5 May 2012 at 21:24:50 UTC, Chris Cain wrote:
> On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote:
>> Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are.
>
> Out of curiosity, why would you need to "know" which parameters
> are size_t? True, size_t is either uint or ulong and you can't
> really know for sure if you have a uint or ulong and it was
> actually a size_t ... but why would you need to know?

On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:
> That's *such* a lame question...
>
> Even if I _couldn't_ tell you a reason, that'd still be a lame
> question, because the *entire point* of reflection is to access
> type information information about the program... if for nothing
> other than printing it out for the user.
>
> But it's more than that: it's the same darn reason why you need
> to distinguish between
> void* and HWND -- it's an ERROR!
>
> In other words, this must NOT compile!
>
> auto call(F, T...)(F func, T args) { return func(args); }
> void test(uint) { }
> void main() { call!(typeof(&test), size_t)(&test, 1); }
>
> If you're still asking "why shouldn't it compile" then you should
> look up what "type safety" means.
>

That doesn't compile on x86_64.

The point of size_t is to be the native word-sized integer for
the platform, and it does exactly that.

> The point of size_t is to be the native word-sized integer for the platform

"Native word-sized integer" is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
"native" integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)

The point of size_t is for it to be able to represent the size of
something. That's all.

The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.

The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.

Those three need NOT be the same size on the same machine, and
they need NOT be the same as the "fastest" integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard of
it.



> That doesn't compile on x86_64.

I can't tell if you're missing my point or what...
In case that was unclear:
***** I'm saying that shouldn't compile on *ANY* platform. ****

What you're saying is like saying "dchar[] function()" should be
interchangeable with "uint[] function()" just because they're the same data on the same
platform.

Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between them.

Or like saying "HWND function()" and "HANDLE function()" and
"void* function()" should be
interchangeable because they're all the same anyway.

Kind of silly IMO.

I understand you're frustrated, but you don't need to be so
hostile. I agree with most of what you've said on this thread.
And just because I made a short comment doesn't mean I don't know
about std.stdint, sizediff_t, etc. My point was to say that
size_t is supposed to be the size of the architecture's word. I
said nothing about it being the "fastest" type or even whether it
was useful . I would be very interested if you have a better
solution for the integer typing/naming problem.

There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I don't
see that as much of a problem, but others might.




On Sunday, 6 May 2012 at 02:25:54 UTC, Mehrdad wrote:
>> The point of size_t is to be the native word-sized integer for the platform
>
> "Native word-sized integer" is such a blurry term, but of course
> you
> wouldn't know this without understanding why C has a gazillion
> "native" integer types... (hint: if you're trying to justify
> these with today's x86 processors, you're already on the wrong
> track)
>
> The point of size_t is for it to be able to represent the size of
> something. That's all.
>
> The point of sizediff_t is for it to be able to represent the
> difference between two size_t's. That's all.
>
> The point of ptrdiff_t is for it to be able to represent the
> difference between two pointers. That's all.
>
> Those three need NOT be the same size on the same machine, and
> they need NOT be the same as the "fastest" integers on any
> platform.
> That's the whole point of std.stdint, in case you hadn't heard of
> it.
>
>
>
>> That doesn't compile on x86_64.
>
> I can't tell if you're missing my point or what...
> In case that was unclear:
> ***** I'm saying that shouldn't compile on *ANY* platform. ****
>
> What you're saying is like saying "dchar[] function()" should be
> interchangeable with "uint[] function()" just because they're the same data on the same
> platform.
>
> Or like saying class Bar { } and class Foo { } should be
> interchangeable because there's no actual difference between them.
>
> Or like saying "HWND function()" and "HANDLE function()" and
> "void* function()" should be
> interchangeable because they're all the same anyway.
>
> Kind of silly IMO.

On Sunday, 6 May 2012 at 03:15:01 UTC, Matt Peterson wrote:
> I understand you're frustrated, but you don't need to be so hostile.

You're completely right... I apologize about that, it was completely my fault.
I've indeed been pretty frustrated at this typedef nonsense (and the like), since it's made something otherwise elegant become something very annoying and
time-wasting.

To @Chris Cain as well, my response there was rather hostile too -- my apologies about that as well.


> I agree with most of what you've said on this thread. And just because I made a short comment doesn't mean I don't know about std.stdint, sizediff_t, etc. My point was to say that size_t is supposed to be the size of the architecture's word. I said nothing about it being the "fastest" type or even whether it was useful . I would be very interested if you have a better solution for the integer typing/naming problem.

Right, but what I was saying was that that *isn't* what it's meant to be! It's just a *size* type, not a *word* of any kind... (think about systems with interleaving pointers, for example, x86 with segmentation -- the notion of a "word" isn't so obvious anymore, when denoting sizes)


> There definitely needs to be way to define a type that can't implicitly cast to its base type. The problem is that the original typedef did do implicit casting away, and that has potential to cause confusion when porting from C or D1. I don't see that as much of a problem, but others might.

Yeah, I still don't understand what the "potential to cause confusion" was.
Was it *actually* causing a significant problem, or was it just a "potential" problem?