size_t i = to!size_t(1) m;
On 11/14/2012 11:24 PM, Walter Bright wrote:
On 11/14/2012 3:18 AM, Timon Gehr wrote:
template Foo(alias a){ }
struct S{}
alias S X; // ok
alias int Y; // ok
mixin Foo!S; // ok
mixin Foo!int; // not ok
Please fix that. (Everything should be ok.)
Please file a bugzilla for that.
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't need to
write:
auto x = int(1);
suppose I want a size_t?
On 11/15/2012 2:24 AM, Joseph Rushton Wakeling wrote:
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't need to
write:
auto x = int(1);
suppose I want a size_t?
size_t x = 1;
On Wednesday, 14 November 2012 at 22:23:17 UTC, Walter Bright
wrote:
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
But the syntax for built-in types is better, in that you don't
need to write:
auto x = int(1);
If you're going to argue that D should have some facility to
create user-defined
On 2012-11-15 20:32, Era Scarecrow wrote:
Hmmm... Correct me if I'm wrong, but you can create/use opAssign,
correct? Although that doesn't work during initialization...
struct MyInt
{
int i;
ref MyInt opAssign(int rhs) {
i = rhs;
return this;
}
}
MyInt x = MyInt(10);
On 11/15/2012 11:54 AM, Walter Bright wrote:
size_t x = 1;
Complete misunderstanding there -- I'd interpreted Simen's remark as saying that
e.g. auto x = 1; would automatically assign the correct type where builtins were
concerned, and I was pointing out that this wouldn't cover all
On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:
Complete misunderstanding there -- I'd interpreted Simen's remark as
saying that e.g. auto x = 1; would automatically assign the correct type
where builtins were concerned, and I was pointing out that this wouldn't
cover all builtins. Though
On Friday, November 16, 2012 08:26:10 Jacob Carlborg wrote:
On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:
Complete misunderstanding there -- I'd interpreted Simen's remark as
saying that e.g. auto x = 1; would automatically assign the correct type
where builtins were concerned, and I
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright
wrote:
[cut]
Guy makes the argument that users need to be able to extend the
vocabulary of a language and have those new words look like
built-in ones. We have that today, of course, with the ability
of defining new types. There is
On Wednesday, November 14, 2012 10:49:41 renoX wrote:
That's not strictly true: type inference works better for
built-in types than for user-defined types, with auto x = 1; x
is an int, how do I have the same type of syntax for MyInt?
AFAIK I can't, that's why I have mixed feelings towards
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in types than
for user-defined types, with auto x = 1; x is an int, how do I have the same
type of syntax for MyInt?
You can have user-defined literals in D:
auto x = MyInt(1);
On 11/14/2012 10:49 AM, renoX wrote:
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright wrote:
[cut]
Guy makes the argument that users need to be able to extend the
vocabulary of a language and have those new words look like built-in
ones. We have that today, of course, with the
On 2012-43-14 11:11, Walter Bright newshou...@digitalmars.com wrote:
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in
types than
for user-defined types, with auto x = 1; x is an int, how do I have
the same
type of syntax for MyInt?
On Wednesday, November 14, 2012 12:06:29 Simen Kjaeraas wrote:
On 2012-43-14 11:11, Walter Bright newshou...@digitalmars.com wrote:
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in
types than
for user-defined types, with auto x = 1; x
On 11/14/2012 01:53 AM, Walter Bright wrote:
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to one of our
current
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright
wrote:
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language
successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
On 2012-43-14 11:11, Walter Bright newshou...@digitalmars.com wrote:
On 11/14/2012 1:49 AM, renoX wrote:
That's not strictly true: type inference works better for built-in types than
for user-defined types, with auto x = 1; x is an int, how do I
On 11/14/2012 3:18 AM, Timon Gehr wrote:
template Foo(alias a){ }
struct S{}
alias S X; // ok
alias int Y; // ok
mixin Foo!S; // ok
mixin Foo!int; // not ok
Please fix that. (Everything should be ok.)
Please file a bugzilla for that.
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to one of our current
discussions.
Particularly, should we allow:
On 11/14/12, Walter Bright newshou...@digitalmars.com wrote:
Particularly, should we allow:
@identifier
as a user-defined attribute, in potential conflict with future reserved
attribute words, or not?
I would argue that we should strive to implement most new attributes
into libraries.
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright
wrote:
On 11/13/2012 12:56 PM, Walter Bright wrote:
An insightful talk by Guy Steele on what makes a language
successful.
http://www.youtube.com/watch?v=_ahvzDzKdB0
Guy says something interesting in there that's applicable to
On Wednesday, 14 November 2012 at 01:16:15 UTC, Andrej Mitrovic
wrote:
There are some attributes that would probably be very hardor
impossible to implement in a library, e.g. @property
@property is very hard to implement in the compiler!
I could think of
@inline, but that's hardly
On Wednesday, 14 November 2012 at 01:21:37 UTC, Adam D. Ruppe
wrote:
The name follows normal D rules, but the behavior for a
specific name is compiler magic.
BTW by this I mean fully qualified names.
import core.attributes;
@inline void foo(); /* core.attributes.inline is the magical name
Le 14/11/2012 02:16, Andrej Mitrovic a écrit :
There are some attributes that would probably be very hardor
impossible to implement in a library, e.g. @property (..waits for
someone to scream AST macros), but I think there should be very few
of those.
AST MACROS !!!
Actually, that one is
On 11/13/2012 5:19 PM, Chris Nicholson-Sauls wrote:
Still better to worry now, only to concede later, than to develop a hobo stew of
a language. :)
Like all long-lived languages, if D grows old it will be come a hobo stew. Of
course, we must still try to minimize that.
On 11/13/2012 5:16 PM, Andrej Mitrovic wrote:
I would argue that we should strive to implement most new attributes
into libraries.
I think that goes without saying, although it is a hard road to travel.
Consider, for example, the other thread where we are really trying hard to do
unique as a
Walter Bright wrote:
it will be come a hobo stew
... at least one would be able to sell it:
http://www.agrinews.com/wadena/opens/its/arms/to/harvest/thyme/b
istro/story-4936.html
-manfred
On 2012-11-14 01:53, Walter Bright wrote:
Guy says something interesting in there that's applicable to one of our
current discussions.
Particularly, should we allow:
@identifier
as a user-defined attribute, in potential conflict with future reserved
attribute words, or not?
Guy makes
On 2012-11-14 02:16, Andrej Mitrovic wrote:
There are some attributes that would probably be very hardor
impossible to implement in a library, e.g. @property (..waits for
someone to scream AST macros), but I think there should be very few
of those.
Seems I don't have to :)
--
/Jacob Carlborg
30 matches
Mail list logo
