"Walter Bright" <newshound2@digitalmars.com> wrote in message news:k7cko9$hes$1@digitalmars.com...
> On 11/6/2012 6:10 PM, Daniel Murphy wrote:
>> My thoughts exactly.  It reminds me of the horror of C++ exceptions.  I think it would be reasonable to require every annotation is a struct or class.
>
>
> Good analogy. But I'm not sure at this point if that is the right thing to do.

I don't know if it will turn out to be useful either.  But if it's left in there, right or wrong, people will use it and it will be impossible to remove later.

If two libraries both use string literal annotations for metadata (and they will) you can no longer use both on the same declaration at once.  This leads back to C/C++'s global namespace.

As an example:
[3] class Blah {}
What on earth is 3?  Why would you want to attach 3 to a class declaration?
How many different ways are there for libraries to interpret this?

Most importantly, if users still want to experiment with anonymous
annotations, they still can:
[tuple(3)] class Blah {}
Adding speculative features with no use case in mind is a recipe for
disaster.

Much like how you can use extern(C) to force global visibility, you can still get the less hygienic behaviour, if you explicitly ask for it.

We lose nothing.  If it turns out this was the wrong call, built-in types can be restored without breaking a single line of code.

On 2012-11-07 05:19, Walter Bright wrote:
> On 11/6/2012 7:52 PM, bearophile wrote:

> It's a good point, but I have no experience with UDAs. There may be
> emergent behavior with these features that is completely unexpected, and
> we wouldn't find out about it without having it there.
>
> Yes, I know it's a risk.

Exactly, then it's better to start with more restrictions and lift them later as it's needed.

-- 
/Jacob Carlborg

On 06/11/12 17:59, deadalnix wrote:
> Le 06/11/2012 17:46, Walter Bright a écrit :
>> On 11/6/2012 8:27 AM, deadalnix wrote:
>>> OK, I may break all the happiness of that news but . . .
>>>
>>> Tuple in D is notoriously known to be a badly designed feature. Basing
>>> more
>>> stuff on that just because we have them is short sighted and will only
>>> result in
>>> D's tuples being broken forever, several tuples implementations for
>>> more user
>>> confusion, or future major breakage.
>>
>> The only real trouble with tuples is that functions can't return them.
>>
>
> If it is the only problem, we have a pandemic spread of hallucinogen
> trance amongs D users.
>
>>
>>> We still don't have any scheme for a stable D, feature testing or
>>> whatever,
>>
>> Are you aware of the test suite and the auto-tester?
>>
>
> Yes, I'm also aware I hit compiler bugs on a daily basis, that my
> codebase is full of workaround on some of them.
>
>>
>>> Let's not talk these awesome static code analysis tools, java would
>>> become jealous.
>>
>> I have no idea what your point is.
>
> My point is that we have no tooling. Project exists, but they all ends
> up dead at some point or ends up not caring about compatibility that
> much (I'm aware of at least 3 serious D like projects that dropped dmd
> compatibility after spending quite a lot of time on it).
>
> The situation is really bad in that regard (many stuff are
> implementation defined, or even not defined at all because the
> implementation is known to be buggy), and adding surprise, half
> specified features are really not helping.
>
> If you have no idea what my point is, I'm probably wasting my time
> working on D.

If you mean, we should be working on getting the existing stuff working before we think about adding more stuff, I agree 100%.
I would say we're about three years away from it being sensible to work on annotations.
It's reasonable to draft a preliminary proposal (A roadmap, what a novel concept!). But I think it would be a big mistake to do much work on it.

New version up now with a couple reported problems with UDA fixed.

On 2012-39-06 20:11, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-06 19:24, David Nadlinger wrote:
>
>> You are right, UDAs must definitely leverage D's module system for
>> encapsulation/disambiguation. Use of string literals (which are
>> intrinsically »global«) as annotations needs to be explicitly discouraged.
>
> Then why allow it in the first place?
>

Because string literals are just a special case of literals?

i.e. if this works:

struct MyString {
    string s;
    alias s this;
}

@MyString("Foo") int n;

then why should this not work:

@"Foo" int n;

I agree it's useless, but it seems a very arbitrary restriction, too.

-- 
Simen

On 11/07/2012 08:08 AM, Daniel Murphy wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message
> news:k7cko9$hes$1@digitalmars.com...
>> On 11/6/2012 6:10 PM, Daniel Murphy wrote:
>>> My thoughts exactly.  It reminds me of the horror of C++ exceptions.  I
>>> think it would be reasonable to require every annotation is a struct or
>>> class.
>>
>>
>> Good analogy. But I'm not sure at this point if that is the right thing to
>> do.
>
> I don't know if it will turn out to be useful either.  But if it's left in
> there, right or wrong, people will use it and it will be impossible to
> remove later.
>
> If two libraries both use string literal annotations for metadata (and they
> will) you can no longer use both on the same declaration at once.  This
> leads back to C/C++'s global namespace.
>
> As an example:
> [3] class Blah {}
> What on earth is 3?  Why would you want to attach 3 to a class declaration?
> How many different ways are there for libraries to interpret this?
>
> Most importantly, if users still want to experiment with anonymous
> annotations, they still can:
> [tuple(3)] class Blah {}

Then what does this particular restriction buy?

> Adding speculative features with no use case in mind is a recipe for
> disaster.
>
> Much like how you can use extern(C) to force global visibility, you can
> still get the less hygienic behaviour, if you explicitly ask for it.
>
> We lose nothing.  If it turns out this was the wrong call, built-in types
> can be restored without breaking a single line of code.
>

That is never a given in D.

static assert(!is(typeof({struct S{ [2] int x; }})));

Walter Bright, el  6 de November a las 20:19 me escribiste:
> On 11/6/2012 7:52 PM, bearophile wrote:
> >Walter Bright:
> >
> >>But I'm not sure at this point if that is the right thing to do.
> >
> >Why?
> 
> D was fortunate in having 10 years of experience with C++'s exception system to learn from. We don't have that with UDAs.

What? UDAs has been for quite a long time out in the wild, just not in C++.

> >[If you decide to restrict UDAs, then later it will be easy to extend them, it will not break code. While doing the opposite break code. It's you the one that has taught me to design things this way :-) ]
> 
> It's a good point, but I have no experience with UDAs.

OK, that's another thing. And maybe a reason for listening to people having more experience with UDAs than you.

For me the analogy with Exceptions is pretty good. The issues an conveniences
of throwing anything or annotating a symbol with anything instead of just
type are pretty much the same. I only see functions making sense to be accepted
as annotations too (that's what Python do with annotations, @annotation symbol
is the same as symbol = annotation(symbol), but is quite a different language).

-- 

On 2012-11-07 12:05, Leandro Lucarella wrote:

> OK, that's another thing. And maybe a reason for listening to people having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty good. The issues an conveniences
> of throwing anything or annotating a symbol with anything instead of just
> type are pretty much the same. I only see functions making sense to be accepted
> as annotations too (that's what Python do with annotations, @annotation symbol
> is the same as symbol = annotation(symbol), but is quite a different language).

I start to more and more think it would be better to explicitly require the developer to declare an attribute, like:

attribute foo
{
    string name;
}

@foo("asd") int a;

-- 
/Jacob Carlborg

On 2012-11-07 10:06, Simen Kjaeraas wrote:

> Because string literals are just a special case of literals?
>
> i.e. if this works:
>
> struct MyString {
>      string s;
>      alias s this;
> }
>
> @MyString("Foo") int n;
>
> then why should this not work:
>
> @"Foo" int n;
>
> I agree it's useless, but it seems a very arbitrary restriction, too.

That's why I'm starting to think we need to declare an attribute, see my other post:

http://forum.dlang.org/thread/k7bbsu$11ls$1@digitalmars.com#post-k7dijh:242ast:241:40digitalmars.com

-- 
/Jacob Carlborg

Don Clugston, el  7 de November a las 09:23 me escribiste:
> >If you have no idea what my point is, I'm probably wasting my time working on D.
> 
> If you mean, we should be working on getting the existing stuff
> working before we think about adding more stuff, I agree 100%.
> I would say we're about three years away from it being sensible to
> work on annotations.
> It's reasonable to draft a preliminary proposal (A roadmap, what a
> novel concept!). But I think it would be a big mistake to do much
> work on it.

100% agree. It might make a little sense if it were in an experimental branch for people to try out and find bugs. But it makes no sense to keep adding features to the stable branch, when a release should be made soon, out of the blue like this just because Walter woke up one day with an idea.

Seriously Walter, please do some planing and consult with the other developers before committing stuff to the master branch, if you keep treating the language as your own toy. It would be very difficult for people to perceive it as a real open source and community driven project if you keep doing that.

-- 
Luca