On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis wrote:
> If you want anything like this to happen, you'll have to convince Walter and
> Andrei, and I would be shocked if they were ever convinced. They want to focus
> on stability, not on tweaking everything in search of making the language
> perfect. Breaking changes - especially breaking changes on this scale - need
> to provide real, tangible benefits which outweigh the cost of the breakage. And
> changing the @ attributes doesn't even come close.

I tend to lean towards this position with time more and more. Problem is, stuff that bothers me most in D which I'd like to change in a breaking way is not lack of some new features or re-engineering of some specific syntax. Under-explored semantics of some core language parts are most frustrating in my every-day development - like tuples or attribute defaults or symbol visibility. But changing/fixing those will yield completely different language, something like D3, it is not some incremental augmentation.

And when it comes to exiting feature set - D2 is already so much ahead of C++ that  I tend to desire more stability / "industrial quality" to act as replacement right here and now. No single improvement will benefit as much as simple proof that D community can craft tool set that "just works". In that sense, any proposed addition must be either completely in style with existing language state or give really enormous benefits. Being simply good is not enough.

Of course, good stuff is still worth discussing - language design moves forward and D3 is inevitable, whatever Walter intention here is. There are already D derivatives that do experiment in that domain trying to build on D experience foundation in the very same way as D did on top of C/C++. But that is completely different story - D upstream itself must first prove itself capable of producing at least single mature language version / implementation before moving forward.

On Thursday, 7 November 2013 at 20:58:51 UTC, Jacob Carlborg wrote:
> That only works if you always use fully qualified names for your UDA's:
> ...

Btw, what I have meant originally is that if built-in attributes where provided by some runtime module similar to object.d (instead of being part of grammar), one could use specialized imports at module top-level to prioritize them over built-in ones and make transition trivial:
```
import myudamodule : property;

// ...

@property // explicit symbol import has higher priority over normal one, no name clash
void foo() {}
```

On 2013-11-07 23:23, Dicebot wrote:

> Btw, what I have meant originally is that if built-in attributes where
> provided by some runtime module similar to object.d (instead of being
> part of grammar), one could use specialized imports at module top-level
> to prioritize them over built-in ones and make transition trivial:
> ```
> import myudamodule : property;
>
> // ...
>
> @property // explicit symbol import has higher priority over normal one,
> no name clash
> void foo() {}
> ```

Oh, you mean like that. I guess that could work.

-- 
/Jacob Carlborg

On Thursday, 7 November 2013 at 09:29:39 UTC, Daniel Kozak wrote:
> On Thursday, 7 November 2013 at 08:11:53 UTC, WasThere wrote:
>> Anyway adding or removing @ will cause code breakage,
>> but leaving @ for UDAs it's better. It will be beautiful in words of consistency.
>
> Yes, but removing @ from @safe and others will mean more new keywords, so now I can have string system = "Linux" and bool safe = true.... But with adding @ to nothrow and others it will just break code use this keywords

This is important.
I think the least painful path to achieve both consistency and minimum brakage would be to introduce different prefixes for built-in attributes and for user-defined attributes, for example:

#private
@myattr

This still let open the question of a different kind of grouping attributes (eg wrt their influence on mangling) but the latter, at least concerning the ABI, should be less a concern for the developer, but for the implementor.

OTOH, there is some way of distinguishing between UDA and non-UDA: their qualification name. Maybe this could be extended some way (eg prefix all attributes with @, but someway give them names with categories):

@abi!nogc

Yes, it's a bit ugly.

Finally, one suggestion about those long chains of "pure @safe nothrow"

Could mega-attributes be defined?

alias myAttr=(pure @safe nothrow);

myAttr myFunction() {}

?

Some might even be pre-defined in std so that could be part of the standard.

PS public, private and so on have strong C++ history where they are written without @ and this may introduce a bias in our view.

On Thursday, 7 November 2013 at 19:59:28 UTC, Rob T wrote:
> On Thursday, 7 November 2013 at 15:55:47 UTC, Jonathan M Davis wrote:
> [..]
>> Then should public and private be @public and @private in order to be
>> consistent? Then we'd be inconsistent with C++, Java, C# etc. which would make
>> it that much harder for folks to learn D. Would you want @static and @const?
>>
>> I don't think that you can be 100% consistent. If nothing else, as soon as you
>> make one thing consistent, it often ends up being inconsistent with something
>> else. And sometimes consistency costs us. For instance, this is perfectly
>> legal
>>
> [...]
>
> Very good points. It's a balancing act for sure.
>
> The other inconsistencies are having multiple ways of doing the same things
>
> Example
>
> 1) private { }
> 2) private:
> 3) private foo() { ... }
>
> That's more to learn and more to document and different methods may confuse people new to D unless they are already preconditioned to it coming from a language like C++, however sometimes having these options are nice and do serve a useful purpose, although in the example 1 and 2 are redundant and 2 goes against the usual {} scope  concept, which is very unusual in terms of consistency.
>
> --rt

I like that I don't have to repeat private with every declaration.

On Thursday, 7 November 2013 at 22:16:43 UTC, Dicebot wrote:
>
> Of course, good stuff is still worth discussing - language design moves forward and D3 is inevitable, whatever Walter intention here is. There are already D derivatives that do experiment in that domain trying to build on D experience foundation in the very same way as D did on top of C/C++.

This raises a question for me: should we perhaps take a page from X.org [0] and document all the niggling finer points of what the "next D" should be or not be?  It's not gospel (and in the case of X12, may never actually happen), but it's still a useful reflection point and consolidation of the various disparate "should have done" things.  Like pure/safe/immutable holes, virtual/final, what the various forks [1] and experiments [2] are and why they exist, etc.

These points come up in conversations, but as we eschew breaking changes with ever-greater fervour, we should still make note of them.  They don't need to be DIPs (though some of the ones in limbo would be valuable additions [3]), or even extensively described.  If nothing else, it'd be a list of issues we're aware of that could be "better" (like the one in the parent thread) to direct people toward.  A succinct history "why this one part sucks".

-Wyatt

[0] http://www.x.org/wiki/Development/X12/
[1] https://github.com/FeepingCreature/fcc
[2] https://github.com/VoltLang
[3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is important. :<

On 11/08/2013 02:31 PM, Wyatt wrote:
>
> [3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is
> important. :<

Please do. Excerpts:

   struct S
   {
       @property Type foo();       // formal getter
       @property void bar(Type);   // formal setter
       @property ref Type baz();   // ref return getter == auxiliary setter
   }

   // Taking the address reveals the delegate
   static assert(is(typeof(&s.foo) == ref Type delegate()));
   // Changing precedence with parens reveals the returned type
   static assert(is(typeof(&(s.foo)) == Type*));

// ---

   struct S
   {
       Type foo();         // 0-arg function
       void bar(Type n);   // 1-arg function
       ref Type baz();     // 0-arg ref return function
   }
   // Getting address of delegate
   static assert(is(typeof(&s.baz) == ref Type delegate()));
   // Getting address of return
   static assert(is(typeof(&(s.baz)) == Type*));


It completely beats me how anyone can consider this a good idea. Seriously, this is broken. Furthermore, the DIP is too informal and fails to handle all relevant cases. I'd rather get rid of @property completely than to approve of DIP23.


See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes @properties behave like ordinary variables except that their address cannot be taken and there could be more postblit/destructor invocations in a given expression. There is a __traits to get the underlying getter/setter function symbols for properties.)

"Thread hijacking" achievement unlocked ;)

On topic of such wiki page - it is kind of nice to have but lot of potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts.

On Friday, 8 November 2013 at 14:12:04 UTC, Timon Gehr wrote:
>
> See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes @properties behave like ordinary variables except that their address cannot be taken and there could be more postblit/destructor invocations in a given expression. There is a __traits to get the underlying getter/setter function symbols for properties.)

Oh, right, that one.  Whoops.  DIP23 was just the flashpoint for the most recent braw^w discussion.  There were like four, but I just grabbed the link for the one that "looked sorta right" without rereading.  My bad. :V  The point is properties are a furball and need to be fixed, so I'll keep making noise about it from time to time.

-Wyatt

On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:
> "Thread hijacking" achievement unlocked ;)
>
Now, now, I changed the title.  If this were a proper hijack, I'd be trying to extract a ransom (like fixed AAs). ;)

> On topic of such wiki page - it is kind of nice to have but lot of potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts.

I don't think it needs to be that strict.  Optional parentheses are something that there are mixed opinions on, so that should be noted.  It may be better to think of it as "things to reconsider in the next version"-- discuss later, once we have a lot more time with the current stuff and it's actually TIME to hash out the future.

"Not gospel" means it's okay for things like that to be in there.  Heck, compare the vision for X12 with what Wayland [0] is actually shaping up to be: they're...rather different. ;)  (I'm aware that being "the next X11" wasn't Kristian's goal and it was originally an experiment to be folded into X.org, but reality is weird.)

-Wyatt

[0] http://wayland.freedesktop.org/architecture.html