November 07, 2012
On 2012-11-07 14:40, deadalnix wrote:

> I think D has already too many feature, and that many of them can be
> implemented as attribute + AST processing.
>
> D should work toward getting this AST stuff and stop adding new keywords
> all the time.

I completely agree.

-- 
/Jacob Carlborg
November 07, 2012
On Wed, Nov 07, 2012 at 06:57:10AM +0100, Jakob Ovrum wrote:
> On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote:
> >I want to hear what people think about [] at declaration scope and @[] at statement scope. Too complicated to remember?

Inconsistent. I don't like it.


> This is quite bad for a variety of reasons, I'll change my vote for purely having @[] then.

I still prefer @(), for being easier to type on a variety of keyboards.


T

-- 
"Hi." "'Lo."
November 07, 2012
On Tue, 06 Nov 2012 22:53:36 +0100
Artur Skawina <art.08.09@gmail.com> wrote:
> 
> "@[ArgumentList]".
> 

vote++

It has all the benefits of '@(...)' (which are very compelling on
their own), but also has the *ONE* benefit of '[...]': Much less
getting lost in stupid parenthesis, as demonstrated here:
http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org


November 07, 2012
On Wednesday, 7 November 2012 at 08:36:49 UTC, Jacob Carlborg wrote:
> On 2012-11-06 22:53, Walter Bright wrote:
>
>> C++11 has had problems adding new keywords, as about every identifier
>> somewhere has been used by someone's C++ source code, and they don't
>> want to break existing code. So C++11 winds up with awful things like
>> "decltype".
>
> Just create a new attribute, call it "builtin" or something similar, which takes attributes as arguments, i.e.
>
> @builtin(shared) int a;
> @builtin(property) int b;
>
> I'm not suggesting that we should change the existing @shared and @property, I just used them as an example.

I honestly don't get why we keep reinventing the concept of namespaces.
I agree with Jonathan regarding the identifier look-up rules in D.
"std.algorithm.find" really should be *the default* unless the user specifically aliases that to "find" whereas now we have the exact opposite. But even without this we still should use D's already existing namespace solution - *the module system*. We should take a lesson from other platforms such as Java and .NET where everything is neatly organized. Let's stop this global identifiers nightmare!

On that note, here's some things we *should not do*:
- put unrelated random stuff in object.d
- add more redundant ways to define namespaces such as __identifier, builtin(identifier), @attribute(identifier), @identifier, etc, etc..
- add more @keywords because they conflict with global identifiers.
- have _huge_ single modules in Phobos that contain everything and ythe kitchen sink. I still hate with passion the "std.algorithm" "module". It's like opening a shop called "A Shop" or naming a newspaper "Newspaper".

Proper organization is not inherently evil and we should not complicate the language design to compensate our current sloppiness.
November 07, 2012
On Wed, 07 Nov 2012 15:51:50 -0000, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Tue, 06 Nov 2012 22:53:36 +0100
> Artur Skawina <art.08.09@gmail.com> wrote:
>>
>> "@[ArgumentList]".
>>
>
> vote++
>
> It has all the benefits of '@(...)' (which are very compelling on
> their own), but also has the *ONE* benefit of '[...]': Much less
> getting lost in stupid parenthesis, as demonstrated here:
> http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

I hadn't replied to this thread earlier because I didn't have a strong opinion either way, but, this suggestion appears to be the best of both worlds. So..

vote++

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 07, 2012
Am Wed, 07 Nov 2012 09:19:41 +0100
schrieb "John Chapman" <johnch_atms@hotmail.com>:

> > [ ArgumentList ]
> >
> > Pros:
> >     precedent with C#
> 
> And Delphi.

That adds to the user base, but it is possible that in both cases Anders Hejlsberg was responsible for the design decision, making it more like a CDelphi# feature. :)

-- 
Marco

November 07, 2012
On 11/06/2012 08:18 PM, Walter Bright wrote:
>
> @( ArgumentList )
>
> ...

I do not like that one as I already use the syntax.
November 07, 2012
On Wednesday, 7 November 2012 at 11:29:16 UTC, Simen Kjaeraas wrote:
> On 2012-12-07 11:11, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
>>> On 2012-19-07 09:11, John Chapman <johnch_atms@hotmail.com> wrote:
>>>
>>>> Personally, I also like <ArgumentList>.
>>>
>>> I am glad to say this will not happen. <> as delimiters cause problems
>>> because they're used elsewhere as non-matching:
>>>
>>> <MyAttribute(foo > bar)>
>>>
>>
>> This example does not show that they cause problems.
>
> Not true. The compiler certainly can handle it, but a programmer could
> easily be confused.

I'm not putting it forward for consideration, but there is a precedent in Visual Basic - http://msdn.microsoft.com/en-US/library/h3z05kek%28v=vs.80%29.aspx
November 07, 2012
Am 06.11.2012 20:18, schrieb Walter Bright:
> For User Defined Attributes.
>
> In the north corner we have the current champeeeeon:
>
> -------
> [ ArgumentList ]
>
> Pros:
>      precedent with C#
>      looks nice
>
> Cons:
>      not so greppable
>      parsing ambiguity with [array literal].func();
>
> ------
> In the south corner, there's the chaaaaallenger:
>
> @( ArgumentList )
>
> Pros:
>      looks like existing @attribute syntax
>      no parsing problems
>
> Cons:
>      not as nice looking
> ------
>
> No hitting below the belt! Let the games begin!


Already too late to the party. I join my voice to the @() group.

--
Paulo
November 07, 2012
On Wednesday, 7 November 2012 at 16:55:23 UTC, Marco Leise wrote:
> Am Wed, 07 Nov 2012 09:19:41 +0100
> schrieb "John Chapman" <johnch_atms@hotmail.com>:
>
>> > [ ArgumentList ]
>> >
>> > Pros:
>> >     precedent with C#
>> 
>> And Delphi.
>
> That adds to the user base, but it is possible that in both
> cases Anders Hejlsberg was responsible for the design
> decision, making it more like a CDelphi# feature. :)

Actually, C# got there first, Delphi not until 2010.