Trass3r:
> Nobody got an answer?
My opinion:
- complex types will be removed. And as far as I know complex number literals
too will be removed from D (this is less nice).
- I am not sure regarding C-style struct initializations. They are useful to
save some typing if you have to for example to p
On 05/31/2010 02:14 PM, bearophile wrote:
Trass3r:
Nobody got an answer?
My opinion:
- complex types will be removed. And as far as I know complex number literals
too will be removed from D (this is less nice).
- I am not sure regarding C-style struct initializations. They are useful to
save
Andrei Alexandrescu:
> typedef is gone.
*mewls* I have shown here some examples of typedef usage, and I'll keep posting
few more in future. I'd like to pull it back from the grave and keep it :-)
Bye,
bearophile
Doesn't
struct T { R _payload; }
accomplish the same thing as
typedef R T;
in the majority of useful cases?
I use typedef void* Some_C_Type; a lot, and rather like it for a
handful of other things, but I'm pretty sure the struct accomplishes
the same thing in those cases. As a template in the
On 05/31/2010 03:54 PM, bearophile wrote:
Andrei Alexandrescu:
typedef is gone.
*mewls* I have shown here some examples of typedef usage, and I'll keep posting
few more in future. I'd like to pull it back from the grave and keep it :-)
It's wasted time. typedef is gone.
Andrei
On 05/31/2010 04:11 PM, Adam Ruppe wrote:
Doesn't
struct T { R _payload; }
accomplish the same thing as
typedef R T;
in the majority of useful cases?
Exactly. And with alias this and other mechanisms, you can define
several well-defined typedef incarnations that achieve what you want to
e
On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> On 05/31/2010 03:54 PM, bearophile wrote:
>> Andrei Alexandrescu:
>>> typedef is gone.
>>
>> *mewls* I have shown here some examples of typedef usage, and I'll
>> keep posting few more in future. I'd like to pull it back from the
>> grave and keep it :
On 05/31/2010 03:54 PM, bearophile wrote:
Andrei Alexandrescu:
typedef is gone.
*mewls* I have shown here some examples of typedef usage, and I'll keep posting
few more in future. I'd like to pull it back from the grave and keep it :-)
Bye,
bearophile
user specified T.init?
On 1-6-2010 6:25, Ellery Newcomer wrote:
> user specified T.init?
I love(d) that feature!
On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu
wrote:
>
> On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> > On 05/31/2010 03:54 PM, bearophile wrote:
> >> Andrei Alexandrescu:
> >>> typedef is gone.
> >>
> >> *mewls* I have shown here some examples of typedef usage, and I'll
> >> keep postin
So what would be the way to translate those Windows headers? Create a
unique struct for each old typedef? With alias this, and a ctor? Well,
if that's the way to do it now, why not make typedef a shortcut for
exactly that!?
Yeah there must be some short and clean way to define it.
IIRC typede
Lionello Lunesu wrote:
I also miss typedef. I thought D had a great opportunity to fix it.
Take something like the Windows headers. It mostly consists of typedefs
for handles and whatnot. Without typedef you'd have to use alias and
type safety is out of the windows.
So what would be the way t
Justin Spahr-Summers, el 31 de mayo a las 16:41 me escribiste:
> On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu
> wrote:
> >
> > On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> > > On 05/31/2010 03:54 PM, bearophile wrote:
> > >> Andrei Alexandrescu:
> > >>> typedef is gone.
> > >>
> > >> *m
On 05/31/2010 10:07 PM, Simen kjaeraas wrote:
Lionello Lunesu wrote:
I also miss typedef. I thought D had a great opportunity to fix it.
Take something like the Windows headers. It mostly consists of typedefs
for handles and whatnot. Without typedef you'd have to use alias and
type safety is
struct Typedef( T ) {
T payload;
alias payload this;
}
alias Typedef!int myInt;
There you go.
The question is if this still works flawlessly for complicated examples.
On Mon, 31 May 2010 23:31:18 -0300, Leandro Lucarella
wrote:
>
> Justin Spahr-Summers, el 31 de mayo a las 16:41 me escribiste:
> > On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu
> > wrote:
> > >
> > > On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> > > > On 05/31/2010 03:54 PM, bearophil
On Tue, 01 Jun 2010 05:07:21 +0200, Simen kjaeraas wrote:
> Lionello Lunesu wrote:
>
>> I also miss typedef. I thought D had a great opportunity to fix it.
>>
>> Take something like the Windows headers. It mostly consists of typedefs
>> for handles and whatnot. Without typedef you'd have to use
Leandro Lucarella Wrote:
> I think he talks about this difference:
>
> alias int a1;
> alias int a2;
> typedef int t1;
> typedef int t2;
>
> void fa(a2 a) {}
> void ft(t2 t) {}
>
> void main() {
> a1 a = 5;
> fa(a); // <--- compiles fine
> t1 t = 10;
> ft(t); // <--- err
On 1-6-2010 12:05, Justin Spahr-Summers wrote:
> On Mon, 31 May 2010 23:31:18 -0300, Leandro Lucarella
> wrote:
>>
>> Justin Spahr-Summers, el 31 de mayo a las 16:41 me escribiste:
>>> On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu
>>> wrote:
On 1-6-2010 5:38, Andrei Alexandrescu
On 1-6-2010 18:04, Kagamin wrote:
> Leandro Lucarella Wrote:
>
>> I think he talks about this difference:
>>
>> alias int a1;
>> alias int a2;
>> typedef int t1;
>> typedef int t2;
>>
>> void fa(a2 a) {}
>> void ft(t2 t) {}
>>
>> void main() {
>> a1 a = 5;
>> fa(a); // <--- compiles fine
On 1-6-2010 11:37, Andrei Alexandrescu wrote:
> On 05/31/2010 10:07 PM, Simen kjaeraas wrote:
>> Lionello Lunesu wrote:
>>
>>> I also miss typedef. I thought D had a great opportunity to fix it.
>>>
>>> Take something like the Windows headers. It mostly consists of typedefs
>>> for handles and wha
Lionello Lunesu Wrote:
> On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> > On 05/31/2010 03:54 PM, bearophile wrote:
> >> Andrei Alexandrescu:
> >>> typedef is gone.
> >>
> >> *mewls* I have shown here some examples of typedef usage, and I'll
> >> keep posting few more in future. I'd like to pull i
On 06/02/2010 10:21 AM, lurker wrote:
Lionello Lunesu Wrote:
On 1-6-2010 5:38, Andrei Alexandrescu wrote:
On 05/31/2010 03:54 PM, bearophile wrote:
Andrei Alexandrescu:
typedef is gone.
*mewls* I have shown here some examples of typedef usage, and
I'll keep posting few more in future. I'd
I suggested eliminating typedef exactly because it was ill-defined and
it was lacking rigorous semantics. Walter agreed to eliminating it
exactly because he was unable to ground typedef's definition. Also,
progress in other, better-defined areas of the language afford us to
implement typede
Andrei Alexandrescu wrote:
struct Typedef( T ) {
T payload;
alias payload this;
}
alias Typedef!int myInt;
There you go.
Yah, perfect - that would be the subtype. I think we should work on
adding a pseudo-supertype as well, and also on a completely independent
type. Then we can add thes
On 6/2/10, Simen kjaeraas wrote:
*snip*
I haven't tried your code, but it looks similar to my own code, which
had this problem:
alias Typedef!Int Handle;
alias Typedef!Int OtherHandle;
void foo(Handle h) { }
OtherHandle b;
foo(b); // compiles, but shouldn't. Problem is that Handle and
OtherHa
On Wed, 02 Jun 2010 23:12:38 +0200, Adam Ruppe
wrote:
On 6/2/10, Simen kjaeraas wrote:
*snip*
I haven't tried your code, but it looks similar to my own code, which
had this problem:
alias Typedef!Int Handle;
alias Typedef!Int OtherHandle;
void foo(Handle h) { }
OtherHandle b;
foo(b); //
How cool! I like that a lot.
Simen kjaeraas:
> My code sidesteps that by including instantiation line and file,
> making each instantiation unique (as long as you don't do
> multiple typedefs on one line).
Cute :-)
We can also try to add/invent something similar to the CLisp gensym, that
generates ever different symbols at c
On Thu, 03 Jun 2010 00:02:03 +0200, Simen kjaeraas wrote:
> On Wed, 02 Jun 2010 23:12:38 +0200, Adam Ruppe
> wrote:
>
>> On 6/2/10, Simen kjaeraas wrote: *snip*
>>
>> I haven't tried your code, but it looks similar to my own code, which
>> had this problem:
>>
>> alias Typedef!Int Handle;
>> al
On 3-6-2010 14:58, Lars T. Kyllingstad wrote:
> On Thu, 03 Jun 2010 00:02:03 +0200, Simen kjaeraas wrote:
>
>> On Wed, 02 Jun 2010 23:12:38 +0200, Adam Ruppe
>> wrote:
>>
>>> On 6/2/10, Simen kjaeraas wrote: *snip*
>>>
>>> I haven't tried your code, but it looks similar to my own code, which
>>>
My suggestion is to just improve the built-in typedef, instead of trying to
implement some hack in D.
Lionello Lunesu:
> Cool trick indeed, but why do we need a trick for something so basic!?
For that a gensym is better than the date/file pair. But a gensym() despite
being a simple thing might
On 6/3/10, bearophile wrote:
> My suggestion is to just improve the built-in typedef, instead of trying to
> implement some hack in D.
Do you consider ALL library solutions to be "hacks"? It sure seems
that way at times.
What we have here is individually useful language features able to
complete
On 06/03/2010 12:17 PM, Adam Ruppe wrote:
On 6/3/10, bearophile wrote:
My suggestion is to just improve the built-in typedef, instead of trying to
implement some hack in D.
Do you consider ALL library solutions to be "hacks"? It sure seems
that way at times.
What we have here is individually
Adam Ruppe:
> Do you consider ALL library solutions to be "hacks"? It sure seems
> that way at times.
I have seen some situations where library solutions are not good enough yet:
- std.bitmanip.bitfields is a marvel of programming, but it's trash any way:
its code can't be maintained, modified, r
On 6/3/10, bearophile wrote:
> I have seen some situations where library solutions are not good enough yet:
> - std.bitmanip.bitfields is a marvel of programming, but it's trash any way:
> its code can't be maintained, modified, read. It's past the limit of
> decency.
When it comes to code access
Adam Ruppe:
> When it comes to code accessibility, the compiler is a black box. You
> can't edit it, even in theory, without breaking the language. A
> library's source might be ugly, but it is at least available for you
> to play with while still writing valid D code.
Code that can be mantained
Thu, 03 Jun 2010 15:08:08 -0400, Adam Ruppe wrote:
> On 6/3/10, bearophile wrote:
>> I have seen some situations where library solutions are not good enough
>> yet: - std.bitmanip.bitfields is a marvel of programming, but it's
>> trash any way: its code can't be maintained, modified, read. It's p
On 4-6-2010 1:17, Adam Ruppe wrote:
>
> This strikes me as being a supremely elegant solution, not a hack.
struct Typedef( T, T init = T.init, Type type = Type.Sub, string _f =
__FILE__, int _l = __LINE__ ) { ...
Yes, that's a hack.
And it's great that we can do sub, super, independent and p
On 06/04/2010 06:38 AM, Lionello Lunesu wrote:
On 4-6-2010 1:17, Adam Ruppe wrote:
This strikes me as being a supremely elegant solution, not a hack.
struct Typedef( T, T init = T.init, Type type = Type.Sub, string _f =
__FILE__, int _l = __LINE__ ) { ...
Yes, that's a hack.
And it's gr
Andrei Alexandrescu wrote:
> On 05/31/2010 02:14 PM, bearophile wrote:
>> Trass3r:
>>> Nobody got an answer?
>>
>> My opinion:
>> - complex types will be removed. And as far as I know complex number
>> literals too will be removed from D (this is less nice). - I am not sure
>> regarding C-style st
On 06/06/2010 10:23 AM, Lutger wrote:
Andrei Alexandrescu wrote:
On 05/31/2010 02:14 PM, bearophile wrote:
Trass3r:
Nobody got an answer?
My opinion:
- complex types will be removed. And as far as I know complex number
literals too will be removed from D (this is less nice). - I am not sure
On 06/06/2010 10:40 AM, Andrei Alexandrescu wrote:
On 06/06/2010 10:23 AM, Lutger wrote:
Andrei Alexandrescu wrote:
On 05/31/2010 02:14 PM, bearophile wrote:
Trass3r:
Nobody got an answer?
My opinion:
- complex types will be removed. And as far as I know complex number
literals too will be
Ellery Newcomer:
> Ooo Ooo Ooo Can we get rid of them? Pretty pretty please?
Why are you so eager to remove them?
(They are not essential, D has plenty of other ways (maybe even too many) to
instantiate a struct. But I have appreciated C-style struct initializers in D
because they give a more c
On 06/06/2010 10:47 AM, bearophile wrote:
Ellery Newcomer:
Ooo Ooo Ooo Can we get rid of them? Pretty pretty please?
Why are you so eager to remove them?
(They are not essential, D has plenty of other ways (maybe even too many) to
instantiate a struct. But I have appreciated C-style struct i
Ellery Newcomer:
> because they're difficult to disambiguate from function literals (at
> least dmd doesn't do it correctly)
>
> because they entail a lot of lookahead (I don't know, but I suspect they
> are the cause for most of the slowness in my parser)
I see.
Thank you for your recent patch
On 06/06/2010 11:57 AM, bearophile wrote
I see.
Thank you for your recent patches. I think you can fix even bug 4283 too :-)
Bye,
bearophile
I vaguely remember going to great length to ensure my parser did the
exact same thing as what dmd does here
There have been lots of discussions about removing language parts.
I don't want this thread to become yet another one.
I just want to know if (and when) these features will be removed or not.
Especially typedef, which I found quite useful lately.
C-style struct initialization and complex types hav
I just want to know if (and when) these features will be removed or not.
Especially typedef, which I found quite useful lately.
C-style struct initialization and complex types have also been discussed
but are still in.
Nobody got an answer?
And this should go into docs.
And this should go into docs.
True.
51 matches
Mail list logo
