November 14, 2012
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
November 14, 2012
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 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 no special syntax that says "this is a user-defined
> type, not a keyword."
>
> I think this is a compelling argument, and tips the scales in its favor.
> Probably we've been excessively worried about the problems of adding a
> new builtin attribute type.

Thank you for finally realizing. It's the same reason why we have operator overloading, we want user defined types to look like built in types.

-- 
/Jacob Carlborg
November 14, 2012
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
November 14, 2012
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 no special syntax that says "this is a user-defined type, not a keyword."

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 type inference..

BR,
renoX

November 14, 2012
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 type inference..

auto x = MyInt(1);

I don't see what's missing. What about type inference works better for built- in types?

- Jonathan M Davis
November 14, 2012
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);

November 14, 2012
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 ability of defining new
>> types. There is no special syntax that says "this is a user-defined
>> type, not a keyword."
>
> 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 type inference..
>
> BR,
> renoX
>

(I prefer to call it type deduction. The term type inference has another meaning.)

I think you identified the wrong language feature as the cause.
November 14, 2012
On 2012-43-14 11:11, Walter Bright <newshound2@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?
>
> You can have user-defined literals in D:
>
>     auto x = MyInt(1);
>

But the syntax for built-in types is better, in that you don't need to
write:

auto x = int(1);

-- 
Simen
November 14, 2012
On Wednesday, November 14, 2012 12:06:29 Simen Kjaeraas wrote:
> On 2012-43-14 11:11, Walter Bright <newshound2@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?
> > 
> > You can have user-defined literals in D:
> >     auto x = MyInt(1);
> 
> But the syntax for built-in types is better, in that you don't need to write:
> 
> auto x = int(1);

That's only because built-in types have literals built into the language. The type deduction is identical either way. It sounds like your complaint has nothing to do with type deduction then but rather with the fact that literals for user-defined types aren't as pretty as those for the built-in types.

- Jonathan M Davis
November 14, 2012
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 discussions.
>
> Particularly, should we allow:
>
>     @identifier
>
> as a user-defined attribute, in potential conflict with future reserved
> attribute words, or not?
>
> 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 no special syntax that says "this is a user-defined
> type, not a keyword."
>

Well,

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.)

> I think this is a compelling argument, and tips the scales in its favor.
> Probably we've been excessively worried about the problems of adding a
> new builtin attribute type.