On Thu, May 17, 2012 at 04:29:57PM +0200, bearophile wrote:
> H. S. Teoh:
>
> >I have brought this up before. Maybe I should open an enhancement
> >request?
>
> Something like this?
> http://d.puremagic.com/issues/show_bug.cgi?id=5004
[...]
Heh, I've actually voted for that bug before, and forgo
H. S. Teoh:
I have brought this up before. Maybe I should open an
enhancement request?
Something like this?
http://d.puremagic.com/issues/show_bug.cgi?id=5004
Bye,
bearophile
On Thu, May 17, 2012 at 03:04:00PM +0200, Andrej Mitrovic wrote:
> On 5/17/12, Jonathan M Davis wrote:
> > The compiler _might_
>
> Clang already does this with C++ for error messages, I see no reason
> why DMD shouldn't do the same.
I have brought this up before. Maybe I should open an enhancem
On 5/17/12, Jonathan M Davis wrote:
> The compiler _might_
Clang already does this with C++ for error messages, I see no reason
why DMD shouldn't do the same.
On Thursday, May 17, 2012 02:38:13 Jonathan M Davis wrote:
> On Thursday, May 17, 2012 11:16:08 Mehrdad wrote:
> > Ugh, ran into a problem again...
> >
> > I was hoping I could do a type deduction for a write() function I
> > had, based on whether the input is 'size_t' (in which case it'd
> > be h
On Thursday, May 17, 2012 11:16:08 Mehrdad wrote:
> Ugh, ran into a problem again...
>
> I was hoping I could do a type deduction for a write() function I
> had, based on whether the input is 'size_t' (in which case it'd
> be hexadecimal) or 'uint' (in which case it'd be decimal), but
> nope! that
Ugh, ran into a problem again...
I was hoping I could do a type deduction for a write() function I
had, based on whether the input is 'size_t' (in which case it'd
be hexadecimal) or 'uint' (in which case it'd be decimal), but
nope! that doesn't work. :(
Any chance we'll be able to di
On 05/11/2012 10:14 PM, Andrej Mitrovic wrote:
On 5/11/12, Steven Schveighoffer wrote:
Since null is its own type now..
What were the use-cases for making it a type? Seems odd to declare it:
typeof(null) x;
I mean what could you do with such a type?
eg. IFTI.
Object x;
void foo(T)(T arg
On Friday, 11 May 2012 at 22:58:02 UTC, Robert DaSilva wrote:
cast voids the warranty, especially cast(typeof(null))
To be honest, I was surprised that a black hole didn't open up
and kill me for what I did.
On Friday, 11 May 2012 at 20:23:18 UTC, Chris Cain wrote:
On Friday, 11 May 2012 at 20:14:29 UTC, Andrej Mitrovic wrote:
On 5/11/12, Steven Schveighoffer wrote:
Since null is its own type now..
What were the use-cases for making it a type? Seems odd to
declare it:
typeof(null) x;
I mean w
On Friday, 11 May 2012 at 20:14:29 UTC, Andrej Mitrovic wrote:
What were the use-cases for making it a type?
Passing it to templates, where the type has to be inferred to
something at a point where it is not yet clear what the value
will actually be assigned to – without a special type for nu
On Friday, 11 May 2012 at 20:14:29 UTC, Andrej Mitrovic wrote:
On 5/11/12, Steven Schveighoffer wrote:
Since null is its own type now..
What were the use-cases for making it a type? Seems odd to
declare it:
typeof(null) x;
I mean what could you do with such a type?
It apparently implicit
On 5/11/12, Steven Schveighoffer wrote:
> Since null is its own type now..
What were the use-cases for making it a type? Seems odd to declare it:
typeof(null) x;
I mean what could you do with such a type?
On Fri, May 11, 2012 at 03:04:52PM -0400, Steven Schveighoffer wrote:
[...]
> struct S
> {
> int x;
> static S opNull() { return S(0);}
> }
>
> S s = null; // equivalent to S(0);
[...]
Wait, is this existing syntax, or proposed syntax?
It would be mindblowingly awesome if it was existing syn
On Friday, 11 May 2012 at 19:04:52 UTC, Steven Schveighoffer
wrote:
This is a frequent problem with null. Since null is its own
type now, it doesn't play nice with custom types, only builtins
enjoy special treatment for null.
It is? O_O
(welcome to Python, lol...)
probably somet
On Fri, 11 May 2012 14:56:45 -0400, Mehrdad wrote:
Okay, I just tried changing "alias void*" to "alias Typedef(void*)", and
also "alias HANDLE" to "alias Typedef(HANDLE)", etc.
First error I got?
HMODULE hAdvapi32 = null;
...\src\phobos\std\internal\windows\advapi32.d(32):
Okay, I just tried changing "alias void*" to "alias
Typedef(void*)", and also "alias HANDLE" to "alias
Typedef(HANDLE)", etc.
First error I got?
HMODULE hAdvapi32 = null;
...\src\phobos\std\internal\windows\advapi32.d(32):
Error:
cannot implicitly convert expression (n
Am 09.05.2012 11:53, schrieb Jonathan M Davis:
> On Wednesday, May 09, 2012 10:00:37 mta`chrono wrote:
Maybe it's not directly related to this topic, but shouldn't that be
rather part of druntime?
>>>
>>> Only if something else in druntime needs it, which it doesn't.
>>>
>>> - Jonathan M
"Mehrdad" , dans le message (digitalmars.D:166381), a écrit :
> On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote:
>> On Mon, 07 May 2012 15:48:22 -0400, Mehrdad
>> wrote:
>>
>> I'm looking at this:
>>
>> m += 5; // ok
>> m = m + 5; // error
>>
>> And thinking, hm.. this is no goo
On Wednesday, May 09, 2012 10:00:37 mta`chrono wrote:
> >> Maybe it's not directly related to this topic, but shouldn't that be
> >> rather part of druntime?
> >
> > Only if something else in druntime needs it, which it doesn't.
> >
> > - Jonathan M Davis
>
> There is a real trend to purify the
>> Maybe it's not directly related to this topic, but shouldn't that be
>> rather part of druntime?
>
> Only if something else in druntime needs it, which it doesn't.
>
> - Jonathan M Davis
There is a real trend to purify the language. I also think it's the
right decision to replace compiler int
On Tuesday, May 08, 2012 20:58:50 mta`chrono wrote:
> Am 08.05.2012 16:03, schrieb bearophile:
> > Steven Schveighoffer:
> >> But making std.typecons.TypeDef work *is* a valid path to get what you
> >> want (typedefs that work like they used to). If that isn't possible,
> >> let's fix the language
Am 08.05.2012 16:03, schrieb bearophile:
> Steven Schveighoffer:
>
>> But making std.typecons.TypeDef work *is* a valid path to get what you
>> want (typedefs that work like they used to). If that isn't possible,
>> let's fix the language constructs that are blocking it!
>
> Right.
>
> Bye,
> b
Steven Schveighoffer:
But making std.typecons.TypeDef work *is* a valid path to get
what you want (typedefs that work like they used to). If that
isn't possible, let's fix the language constructs that are
blocking it!
Right.
Bye,
bearophile
There's an _is_ expression, which allows one to determine the
underlying type of a enum:
template EnumType(T)
if(is(T U = enum))
{
alias U EnumType;
}
It would be awesome if the same mechanism was implemented for aliased types:
template AliasType(T)
if(is(T U = alias))
{
enum str
On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote:
On Mon, 07 May 2012 15:48:22 -0400, Mehrdad
wrote:
I'm looking at this:
m += 5; // ok
m = m + 5; // error
And thinking, hm.. this is no good :)
Yeah, that means they were implemented poorly. :P
It should've been an error fo
On Mon, 07 May 2012 15:48:22 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
I think it was more that the whole concept was flawed -- typedef int
myint never really did exactly what you wanted it to.
For example:
myint m = 1; // ok
m += 5; // ok
m =
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
Seriously though, I get what you are saying. Fortunately, we
have a very significant team working on phobos (I think more
than a dozen people have commit rights), so the situation for
"grr... phobos really should do *this*, but
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
I think it was more that the whole concept was flawed --
typedef int myint never really did exactly what you wanted it
to.
For example:
myint m = 1; // ok
m += 5; // ok
m = m + 5; // error?
It's definitely an error, because
On Mon, 07 May 2012 14:08:33 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 17:17:55 UTC, Steven Schveighoffer wrote:
Nothing in this whole thread seems to be very useful. I don't know how
else to answer your post except -- sorry, we're not going to change it.
Okay.
Though you'd be a lot
On Monday, 7 May 2012 at 17:17:55 UTC, Steven Schveighoffer wrote:
Nothing in this whole thread seems to be very useful. I don't
know how else to answer your post except -- sorry, we're not
going to change it.
Okay.
Though you'd be a lot more convincing if you could give an
example of how t
On Mon, 07 May 2012 12:10:20 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 12:18:36 UTC, Steven Schveighoffer wrote:
No, they are the same function. size_t is aliased to uint. What *you*
want size_t to mean is not what it is, it's an alias to the word-sized
unsigned integer on a platform
On Monday, 7 May 2012 at 12:18:36 UTC, Steven Schveighoffer wrote:
No, they are the same function. size_t is aliased to uint.
What *you* want size_t to mean is not what it is, it's an alias
to the word-sized unsigned integer on a platform. Get used to
it, use another type if you don't want i
On Sun, 06 May 2012 10:58:52 -0400, Mehrdad wrote:
You're missing the problem:
(1) I'm saying function(size_t) and function(uint) are different
functions, and people are telling me that's silly, who cares about the
type anyway. That's not an 'alternative'.
No, they are the same function.
Am 06.05.2012 14:22, schrieb John Campbell:
> On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
>> Now it's impossible to figure out whether a ParameterTypeTuple
>> contains an HWND versus an HGDIOBJ or whatever...
>>
>> this should really be fixed...
>
> Since I don't see it discussed in th
On 5/6/12, John Campbell wrote:
> Since I don't see it discussed in this thread: Which problems do
> you have with http://dlang.org/phobos/std_typecons.html#Typedef?
Here's one:
struct Class
{
mixin CompositeFields;
SymID[] baseIDs; // indexed base class IDs
}
alias std.typecons.Typedef
On Sunday, 6 May 2012 at 14:58:53 UTC, Mehrdad wrote:
Well, it's not *quite* like I was saying "I shouldn't have to
give a reason".
Rather, I was saying that, when you're doing reflection, you
should have access to all information, even if it looks useless.
I understand that, I was just statin
On Sunday, 6 May 2012 at 12:04:52 UTC, Chris Cain wrote:
Also, just as a heads up: If you want language features to be
added (or re-added in this case), saying "I shouldn't have to
give a reason" is an extremely bad way to start. You should
look through a lot of old threads. Even when people so
On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
Since I don't see it discussed in this thread: Which problems do
you have with http://dlang.o
On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:
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.
Also,
On 2012-05-05 18:20:44 +, "Mehrdad" said:
How do you fix it for size_t and uint, etc.?
I'm not sure what problem you're seeing. You can do the same with any type.
struct PineappleSize { size_t size; }
If you need operators to work, define them. If you need the new type to
be a
On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote:
To @Chris Cain as well, my response there was rather hostile
too -- my apologies about that as well.
It's OK. The only reason I was asking is because I may have been
able to offer you a better alternative to what you're actually
trying to
On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote:
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" is
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'
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 architec
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 proc
On Saturday, May 05, 2012 20:43:40 Mehrdad wrote:
> Er, the point is, there are functions ALREADY using size_t, and I
> need to figure out which parameters those are.
In what situation would it matter? If you're writing the code yourself, then
you have access to the function and can see that it's
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 prin
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
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
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 solutio
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 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 U
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
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 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.
--
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.
See my version.
On Sat, May 5, 2012 at 10:20 PM, Mehrdad wrote:
> How do you fix it for size_t and uint, etc.?
>
>
> On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
>>
>> On 2012-05-05 05:02:44 +, "Mehrdad" said:
>>
>>> Now it's impossible to figure out whether a ParameterTypeT
How do you fix it for size_t and uint, etc.?
On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
On 2012-05-05 05:02:44 +, "Mehrdad"
said:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fi
mixin template TypeDef(Type, string name, Type init)
{
mixin(`struct `~name~` { public alias _impl this; private Type
_impl = init; };`);
}
unittest
{
mixin TypeDef!(int, `MyInt`, 5);
MyInt mi;
assert(typeid(myInt) != typeid(int));
assert(mi == 5);
}
On Sat, May 5, 2012 at 3
On 2012-05-05 05:02:44 +, "Mehrdad" said:
Now it's impossible to figure out whether a ParameterTypeTuple contains
an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
It should be fixed indeed. Perhaps HWND should be defined more like this:
struct HWND { void
Mehrdad:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
typedef is a quite useful feature, but the one present in D was
unsound/broken, especially in presence of OOP. Fixing language
features is
(Sorry that wasn't meant to be directed at you, I just happened
to click reply on your post)
On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote:
On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus
And for those who couldn't care less about Windows, I should also
note that it's impossible to distinguish between size_t and uint,
etc.
On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote:
On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
Now it's impossible to figure out whether
On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
Features like this:
typedef int type = 5;
type var;
var.init; // is 5
AFAIK are also lost.
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
64 matches
Mail list logo
