"Steven Schveighoffer"  wrote in message news:m7sh3h$1co$1@digitalmars.com...
>
> I think it wouldn't be a bad idea to investigate a new way to express attributes, but I think no matter what we do, we need to rein in the explosion of attributes that needs to be put on every function.

'\' is now free since we got rid of delimited strings.  We could start introducing a new set of keywords starting with \ref until D looks like latex. 

On 12/29/2014 9:39 PM, Daniel Murphy wrote:
> '\' is now free since we got rid of delimited strings.  We could start
> introducing a new set of keywords starting with \ref until D looks like latex.

It's already been done:

    life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

  -- http://en.wikipedia.org/wiki/APL_(programming_language)#Examples

On 12/29/14 8:10 PM, Manu via Digitalmars-d wrote:
> On 30 December 2014 at 07:29, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 12/29/14 3:42 PM, Dicebot wrote:
>>
>> I think it wouldn't be a bad idea to investigate a new way to express
>> attributes, but I think no matter what we do, we need to rein in the
>> explosion of attributes that needs to be put on every function.
>
> The approach is to infer everything, right?
> The only time you are required to make it explicit is when it's an
> important detail of your API, and you want to receive compile errors
> when you violate such explicit request.
>

This only works for templates. Unless we devise a new object scheme and linker...

But I agree. The problem is, most times, you WANT to ensure your code is @safe pure nothrow (and now @nogc), even for template functions. That's a lot of baggage to put on each signature. I just helped someone recently who wanted to put @nogc on all the std.datetime code, and every signature had these 4 attributes except a few. I tried to have him put a big @safe: pure: nothrow: @nogc: at the top, but the occasional exceptions made this impossible.

It's unfortunate we couldn't start with these being the defaults, and then add the occasional @system, @unpure, and @throws where appropriate.

Some mechanism of aliasing attribute combinations is itching to get done :)

-Steve

On Tue, 30 Dec 2014 07:14:24 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> But I agree. The problem is, most times, you WANT to ensure your code is @safe pure nothrow (and now @nogc), even for template functions. That's a lot of baggage to put on each signature. I just helped someone recently who wanted to put @nogc on all the std.datetime code, and every signature had these 4 attributes except a few. I tried to have him put a big @safe: pure: nothrow: @nogc: at the top, but the occasional exceptions made this impossible.
> 
> It's unfortunate we couldn't start with these being the defaults, and then add the occasional @system, @unpure, and @throws where appropriate.
> 
> Some mechanism of aliasing attribute combinations is itching to get done :)

or at least the way to "undo" some attributes. we can "undo" "@safe", but what about "notrhow"? "@nogc"? "const"? and, by the way, "final" and "static"!

it's very handy to write something like this:
final:
nothrow:
@nogc:
  void foo () { ... }
  ...
  // and ocasionally we need this:
  virtual bar () throw @gc { ... }
  // and go on with 'final nothrow @nogc'
  ...

sure, we can move `bar` to another place, or make ugly nestes "{}" blocks, or invent some other workarounds. but they are still workarounds, and this frustrates me alot. if we have a way to make something default (`final:`), we MUST have a way to cancel that defaults both temporary and permanently.

another nice D feature that is half-done.

On Monday, 29 December 2014 at 20:42:37 UTC, Dicebot wrote:
> On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer wrote:
>> But this precludes doing anything with a mutable t inside foo, since inout means "const within the function".
>
> Hm, yes, this is indeed quite the problem. I have totally forgot that compiler has no means of figuring out which invocation of inout is currently used.
>
> But something very similar feels necessary to me. There is constness, lifetime, purity - inventing new dedicated keyword for each case does not feel like scaling approach. Especially when existing one is named so generic.

I've been pondering this for a while, maybe someone with a better theoretical foundation has an answer...

These concepts you mention (I'd add "type erasure", because that's what `inout` is currently about) are inter-connected and have some overlap with each other. But at the same time, they are still separate concepts.

Do you think they are just aspects of one all-encompassing Grand Unified Concept? Because if they turn out to be fundamentally separate, they are better treated as such, instead of mixing them up. Dedicated keywords may be the way to go if this is the case. (From what I've seen so far, I think they are indeed separate, but who knows?)

In general, I get the impression from both DIP25 and DIP69 that both are motivated by minimizing the change to the existing language, instead of looking for the most powerful solution (that may have other use-cases besides the ones under consideration). I.e., instead of asking which concepts are behind the problem in question, how these concepts could be expressed in an ideal world, and then making compromises to fit them into D, it seems like we're starting with some premises (as few changes as possible, no type modifiers), and then look for a solution that needs to sacrifice the smallest number of use cases to stay within the constraints. This is particularly bad if our premises are going against the nature of the problem we want to solve, because then we are guaranteed to get a bad solution.

On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote:
> On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 12/29/14 2:58 AM, John Colvin wrote:
>>>
>>> On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
>>>>
>>>> There is a rub though. Not only you're telling what we'd need to do to
>>>> be more successful, you're also telling us how to do it. Please don't.
>>>> We are not adding type qualifiers to D if we can avoid it, and
>>>> generally we want to achieve what we need to achieve with minimum
>>>> aggravation. Instead please focus on what you're trying to accomplish,
>>>> not on whether an artifact is a type qualifier or a storage class.
>>>> Thanks.
>>>>
>>>>
>>>> Andrei
>>>
>>>
>>> But (one of) his point(s) is that the choice between type qualifier and
>>> storage class directly impacts his work. Why shouldn't a user express
>>> such a point?
>>
>>
>> Making that point is fine so long as the costs are discussed alongside with
>> the applicability to one particular task. -- Andrei
>
> It's not one particular task. It is the common theme for almost all
> ref related problems (other than rvalue->ref, which is just
> arbitrarily rejected currently).

Not arbitrary at all. The problem with binding rvalues to ref is that subsequently the ref may escape the scope. DIP25 would not have been possible if rvalues bound to ref.

> I'm trying to raise that topic for discussions, but nobody wants to
> talk about it, and would rather focus on patches instead.
> I don't know exactly where ref as type constructor would lead.

That would imply you'd have more restraint in pushing it.

> Sure,
> it would be complex no doubt, but not necessarily any more or less
> complex than the awkward network of edge cases we're trying to deal
> with in these discussions currently.
> My feeling is, all these discussions are essentially arguing an
> *extremely* complex suite of language patches. I'm interested in
> considering the root problem for contrast... I think we'd find
> ourselves in a position with a lot less edges as result.

I think you are wrong about this.


Andrei

On 12/29/14 4:40 PM, Manu via Digitalmars-d wrote:
> On 29 December 2014 at 14:13, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote:
>>> I'd also like to know how this will help DIP69?
>>
>>
>> Just takes the entire ref handling out of the equation.
>
> Then DIP69 seems to lose all purpose?
> The whole thing is about safer indirections.

DIP69 allows defining entire variables with "scope", something DIP25 does not address (but helps enforcing safety for).

> I was giving a context with vibe.d, but I think they key take-aways were:
>
> First-impressions; in our case, that was Windows environment setup,
> but the point should be taken generally, and that includes IDE
> integration. The effect of a poor experience here is eroding user
> confidence before they've even written a single line of code.
> Expectations are high, other programming communities are nailing this.
>
> Debugging was the biggest issue, and turned out to be the dealbreaker.
> We couldn't get behind something that we were unable to fix if we have
> to. (I say 'we', meaning the general office perception, and that
> perception was definitely coloured by the prior experiences re;
> first-impressions)
>
> Also documentation received a lot of criticism from the new-users,
> although I didn't identify it as a deal-breaker. I experienced this
> same frustration myself years ago. It's easy to address, I just wanted
> to demonstrate importance.
>
>
> Trust me that these guys were REALLY excited to try out D when we got
> started. But their confidence was eroded very quickly by these factors
> in aggregate.
> I think D will get another shot with this lot at some later stage when
> demonstrable progress has been made.

Yah, I hear ya. We need to muster talent and funds to make all that happen.

>> Others harbored similar perceptions. The corollary has been that essentially
>> you're asking them to stop working on D aspects they do care about and start
>> working on D aspects you and others care about - all on their free time.
>
> I've already argued against this assertion, because it got kind of
> aggressive. I was just reporting a case-study.
> People can do whatever they want, I'm only trying to reaffirm the
> reality of the importance of the same stuff that I've been going on
> about since the day I showed up here.
> There has been really great improvement, and we're getting awfully
> close to the line, but we're still just a little way short.
>
> It's a shame, because that boring stuff that nobody is interested in
> working on is inhibiting people from getting amongst the cool stuff
> that's going on here.

Yah, and I used to somehow consider the community was at "fault" about it. There is something wrong when people don't have the time to contribute because they're too busy arguing in the forums - even the most trivial matters that would literally take vastly shorter time to actually fix. Then I thought it might be a failure of leadership: it's Walter and I who do something wrong if we're unable to rally the community into action. I'm open to suggestions on how to do better going forward.


Andrei

On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> In general, I get the impression from both DIP25 and DIP69 that both are
> motivated by minimizing the change to the existing language, instead of looking
> for the most powerful solution (that may have other use-cases besides the ones
> under consideration). I.e., instead of asking which concepts are behind the
> problem in question, how these concepts could be expressed in an ideal world,
> and then making compromises to fit them into D, it seems like we're starting
> with some premises (as few changes as possible, no type modifiers), and then
> look for a solution that needs to sacrifice the smallest number of use cases to
> stay within the constraints. This is particularly bad if our premises are going
> against the nature of the problem we want to solve, because then we are
> guaranteed to get a bad solution.

On the other hand, power just because we can add it is not always a good thing. C macros are very powerful, but experience has shown it is the wrong kind of power. Also, programmers do not really want a complex annotation system. They want to just write code in the most obvious manner and have it work correctly. Having a powerful (but complex) system is not very attractive.

On 31 December 2014 at 10:09, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>>
>> In general, I get the impression from both DIP25 and DIP69 that both are
>> motivated by minimizing the change to the existing language, instead of
>> looking
>> for the most powerful solution (that may have other use-cases besides the
>> ones
>> under consideration). I.e., instead of asking which concepts are behind
>> the
>> problem in question, how these concepts could be expressed in an ideal
>> world,
>> and then making compromises to fit them into D, it seems like we're
>> starting
>> with some premises (as few changes as possible, no type modifiers), and
>> then
>> look for a solution that needs to sacrifice the smallest number of use
>> cases to
>> stay within the constraints. This is particularly bad if our premises are
>> going
>> against the nature of the problem we want to solve, because then we are
>> guaranteed to get a bad solution.
>
>
> On the other hand, power just because we can add it is not always a good thing. C macros are very powerful, but experience has shown it is the wrong kind of power. Also, programmers do not really want a complex annotation system. They want to just write code in the most obvious manner and have it work correctly. Having a powerful (but complex) system is not very attractive.

His point is similar to my other point elsewhere though. I don't think he's talking about 'power' in the sense you describe, what he's really talking about is consistency or uniformity. His original scope proposal wasn't 'powerful' (even though it was effectively more powerful), it was holistic, and without the edges that seem to have been introduced to try and 'contain the concept into a smaller space', if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do; talk
about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet more
edges to address specific cases, rather than removing the edges that
are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off rough edges.

On 31 December 2014 at 08:26, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote:
>>
>> On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d
>>
>> <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 12/29/14 2:58 AM, John Colvin wrote:
>>>>
>>>>
>>>> On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
>>>>>
>>>>>
>>>>> There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks.
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>>
>>>>
>>>> But (one of) his point(s) is that the choice between type qualifier and
>>>> storage class directly impacts his work. Why shouldn't a user express
>>>> such a point?
>>>
>>>
>>>
>>> Making that point is fine so long as the costs are discussed alongside
>>> with
>>> the applicability to one particular task. -- Andrei
>>
>>
>> It's not one particular task. It is the common theme for almost all ref related problems (other than rvalue->ref, which is just arbitrarily rejected currently).
>
>
> Not arbitrary at all. The problem with binding rvalues to ref is that subsequently the ref may escape the scope. DIP25 would not have been possible if rvalues bound to ref.

However this code is perfectly legal:

void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
  int onStack = 1;
  mayEscape(onStack); // <- perfectly legal, and equally unsafe
}


While that code is legal, the rejection of rvalue->ref is absolutely arbitrary.
The 'workaround' for not allowing rvalue->ref is to simply assign it
to a stack local with a stupid name (eg: t1, t2, etc) on the preceding
line.
That workaround appears in *every* instance that rvalue->ref would be
used, making code messy and more difficult to maintain.

Obviously, I'm all for scope, and lifetimes and all that to make this stuff properly safe. But the current situation is that we are inconvenienced by an arbitrary decision.

>> I'm trying to raise that topic for discussions, but nobody wants to
>> talk about it, and would rather focus on patches instead.
>> I don't know exactly where ref as type constructor would lead.
>
> That would imply you'd have more restraint in pushing it.

Why? I think there's a serious danger here.
Precedent would lead to me to fear that the sort of reasoning that
lead to 'auto ref' may prevail here again.

>> Sure,
>> it would be complex no doubt, but not necessarily any more or less
>> complex than the awkward network of edge cases we're trying to deal
>> with in these discussions currently.
>> My feeling is, all these discussions are essentially arguing an
>> *extremely* complex suite of language patches. I'm interested in
>> considering the root problem for contrast... I think we'd find
>> ourselves in a position with a lot less edges as result.
>
>
> I think you are wrong about this.

In what way?
I don't see why exploring a more fundamental solution is absolutely
off the table.