Le 14/11/2012 22:13, Walter Bright a écrit :
> On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
>> If "std.mytypes.mystring" is a variable of the type "string" then the
>> fully
>> qualified name is lost if it's used as an attribute. Something like this:
>
> I am having a REALLY hard time making my point here.
>
> struct MyString
> {
> string s;
> }
>
> Now use MyString as an attribute. No, the name is not lost. Yes, two
> different modules can use MyString as an attribute, and impute
> completely different meanings into it.
>
> Just because it is not a builtin type does not change anything.

I seriously feel like I'm in Alice in wonderland here.

A type is a meaning associated to data. For instance, char[] is an array of char. Note that you can store pointers, integer, or basically anything in that memory. But you don't, because this type give you information about what in this memory, and storing anything else would be confusing as hell.

The same way, I can throw a FileExeption every time a problem occurs in any of my programs. That would be insane, but i CAN do that.

Well, the same way, I can subvert attribute in any convoluted way I want to. But that make no sens at all (and I don't expect any codebase using such techniques to become really big).

The whole point of attaching data to a symbol via attribute is to provide a meaning attached to that symbol. The meaning is given by the type, like it does everywhere else.

Your MyString example or an int is a perfect example of a type that have no meaning. Your argument is just like we shouldn't put any protection near a precipice since people can throw themselves over it anyway. Yeah, but at least, they'll do it on purpose and assume the consequences, and that is a huge win.

On 11/14/2012 2:18 AM, Leandro Lucarella wrote:
> Can you provide one concrete case where it makes sense NOT to restrict UDAs to
> types

One where its use is entirely inside the scope of a module, i.e. local use of it. There seems to be an assumption that UDAs are global, but I don't see a reason why that should always be true.


> and it's different from restricting exception to classes derived from
> Exception?

Exceptions leak out of their scopes as an explicit part of their nature. That's the whole point of them, and I think that's the fundamental difference.

On Friday, 16 November 2012 at 13:12:34 UTC, Tove wrote:
> On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright wrote:
>> The whole point of my example was no, you do not necessarily know the meaning of a user-defined type that is used as an attribute.
>
> Agree. Imagine we have 3 generic libs/modules...
> "Optimized CTFE Polygon Primitive Lib", Math, Gfx
> ... and then the "end user", creates a program.
>
> Both Math and Gfx, want to use the optimized Polygon in their modules...
>
> [Polygon(...)]
> struct SpaceShip
> {
> }
>
> This is just as ambiguous as if you had used a built-in int:s... and it can be solved in the exact same way which I outlined in the other thread.

I don't think this is a valid argument. I challenge you to find a single real-world use case where an *annotation* would be so complex that this would make any sense at all, yet it would be impossible (or even just less clear) to just use a wrapper type like @CollisionShape(Polygon(…)) or @RenderBounds(Polygon(…)).

David

On 2012-11-16 11:41, Walter Bright wrote:

>> Sure you _can_ but it would be quite stupid. With user defined types
>> there is at
>> least some context. With a plain string (or any built in type) it can
>> come from
>> any where and mean anything.
>>
>> The difference is, with a user defined type you know the meaning of the
>> attribute, with a built in type you do not, not in the same way at least.
>>
>
> The whole point of my example was no, you do not necessarily know the
> meaning of a user-defined type that is used as an attribute.

i don't know what to say anymore. I can only repeat what I've already said. This conversion has clearly gone into circles.

-- 
/Jacob Carlborg

On Tuesday, 6 November 2012 at 18:49:22 UTC, Walter Bright wrote:
> On 11/6/2012 10:10 AM, Jacob Carlborg wrote:
>> On 2012-11-06 18:00, David Nadlinger wrote:
>>
>>> Yes, it is nice to have a working prototype indeed. What is not so nice
>>> in my opinion, however, is that this first prototype straight to Git
>>> master, without any prior evaluation, at a time where the general goal
>>> is to stabilize the language.
>>
>> Yes, very good point. I don't see why this hasn't been done before, it's dead
>> easy. Just use:
>>
>> $ git checkout -b uda
>> # code
>> $ git commit -a -m "Add support for user defined attributes"
>> $ git push origin uda
>>
>> Walter, why aren't you using branches for these kind of things?
>>
>
> Because I still think in a linear fashion :-)

hehe, how on earth were you able to come up with D in the first place then? ;-p