View mode: basic / threaded / horizontal-split · Log in · Help
November 07, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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
Re: [ ArgumentList ] vs. @( ArgumentList )
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.
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home