On 2013-11-17 09:18, SomeDude wrote:

> True but you will hardly use myfunction as an extension to the language.
>
> If I understand the issues, I quite understand Walter's reluctance to
> add such a feature. Once you add it, you add the capability to change
> the language, or to create an entirely new language. If you let it, no
> matter how loud you cry, people *will* abuse the feature, and they will
> do it from day one. The C++ templates experiment shows what happens when
> you do that. We don't want to repeat the same mistakes.

We already have templates and operator overloading. Perhaps we should remove those, we don't want to take the chance of people abusing them.

> Basically, people want to change the language, but without having to
> discuss their own extensions in the newsgroups. It's sometimes handy,
> but you'll end up with crappy features all over the place.

No, people want a general solution that doesn't require the language to be extended each time they come up with a useful feature.

-- 
/Jacob Carlborg

> Think about the desired feature mentioned earlier in this thread of being able to insert a "return;" statement, causing what looks like a function call to return from the caller.
>
> That's a major step increase in obfuscation, not just a detail.

You do realize that, as per more strict proposal, it won't change a _single_ thing about semantics of actual D function but allows to generate another one with semantics defined by macro?

It has _zero_ added ofbuscation over existing template + traits combo. You have not shown a single example which proves otherwise and keep resorting to personal experience argument instead of doing actual comparison. You have full right to do so but it does not sound like a decision made on behalf of careful reasoning.

On 2013-11-17 11:37, Jacob Carlborg wrote:
> On 2013-11-17 09:58, Walter Bright wrote:
>
>> Think about the desired feature mentioned earlier in this thread of
>> being able to insert a "return;" statement, causing what looks like a
>> function call to return from the caller.
>
> I'm not entirely sure what you're saying. Could you please post a link
> to the post mentioning this or show an example.

I believe it is basically this:

int bar() {
    foo(return 3);
    return 5;
}


If that program is allowed to compile, and to return 3.

On Sunday, 17 November 2013 at 13:36:32 UTC, Simen Kjærås wrote:
> On 2013-11-17 11:37, Jacob Carlborg wrote:
>> On 2013-11-17 09:58, Walter Bright wrote:
>>
>>> Think about the desired feature mentioned earlier in this thread of
>>> being able to insert a "return;" statement, causing what looks like a
>>> function call to return from the caller.
>>
>> I'm not entirely sure what you're saying. Could you please post a link
>> to the post mentioning this or show an example.
>
> I believe it is basically this:
>
> int bar() {
>     foo(return 3);
>     return 5;
> }
>
>
> If that program is allowed to compile, and to return 3.

That never was in the DIP.

On 13.11.2013 20:05, Ellery Newcomer wrote:
> On Wednesday, 13 November 2013 at 10:51:48 UTC, Simen Kjærås wrote:
>> On 12.11.2013 18:53, Ellery Newcomer wrote:
>>
>> It's perfectly possible in D to make this work:
>>
>
> hey, cool impl
>
> *comprehends code*
>
> I mean Ewww
>
>> I *can* make that work. I'm not going to.
>>
>> --
>>   Simen
>
> I concur with the second part.

I decided to abandon sanity. Luckily, only for the named parameters. I now have this code working:


void test(int a, int b = 2, string c = "foo", int d = 14) {
}

alias test2 = nameify!test;

void main() {
     test2(1, Args.d = 4, Args.c = "bar");
}

With reasonable error messages for duplicate and missing parameters, as well as type mismatches.

Source is attached. I hope God forgives me.

-- 
   Simen

On Sun, Nov 17, 2013 at 8:41 PM, Simen Kjærås <simen.kjaras@gmail.com> wrote:

> Source is attached. I hope God forgives me.

Nice ideas. I particularly like this one:

final abstract class Args {
    @property
    static auto opDispatch(string name, Arg)(Arg arg) {
        return NamedArg!(name, Arg)(arg);
    }
}

Which allows you to have Args.c = 1 (and thus storing the name and the value).

Half of your implementation is in fact generic enough to be in Phobos (staticFilter, staticZip). I know I use my own...

Btw, with DMD 2.064.2, we can now write:

template staticToString(T...) {
    enum staticToString = T.stringof;
}

as:

alias staticToString(T...) = T.stringof;

Which is both easier to understand and easier on the eyes.

On Sunday, 17 November 2013 at 19:41:40 UTC, Simen Kjærås wrote:
> On 13.11.2013 20:05, Ellery Newcomer wrote:
>> On Wednesday, 13 November 2013 at 10:51:48 UTC, Simen Kjærås wrote:
>>> On 12.11.2013 18:53, Ellery Newcomer wrote:
>>>
>>> It's perfectly possible in D to make this work:
>>>
>>
>> hey, cool impl
>>
>> *comprehends code*
>>
>> I mean Ewww
>>
>>> I *can* make that work. I'm not going to.
>>>
>>> --
>>>   Simen
>>
>> I concur with the second part.
>
> I decided to abandon sanity. Luckily, only for the named parameters. I
> now have this code working:
>
>
> void test(int a, int b = 2, string c = "foo", int d = 14) {
> }
>
> alias test2 = nameify!test;
>
> void main() {
>      test2(1, Args.d = 4, Args.c = "bar");
> }
>
> With reasonable error messages for duplicate and missing parameters, as
> well as type mismatches.
>
> Source is attached. I hope God forgives me.

That is a really cool idea !

On 11/17/2013 10:47 AM, deadalnix wrote:
> On Sunday, 17 November 2013 at 13:36:32 UTC, Simen Kjærås wrote:
>> On 2013-11-17 11:37, Jacob Carlborg wrote:
>>> On 2013-11-17 09:58, Walter Bright wrote:
>>>
>>>> Think about the desired feature mentioned earlier in this thread of
>>>> being able to insert a "return;" statement, causing what looks like a
>>>> function call to return from the caller.
>>>
>>> I'm not entirely sure what you're saying. Could you please post a link
>>> to the post mentioning this or show an example.
>>
>> I believe it is basically this:
>>
>> int bar() {
>>     foo(return 3);
>>     return 5;
>> }
>>
>>
>> If that program is allowed to compile, and to return 3.
>
> That never was in the DIP.

It was this by Timon Gehr essentially posting why lazy parameters weren't good enough:

> On 11/13/2013 08:25 PM, Walter Bright wrote:
>>>
>>
>> Ah, found the code:
>>
>> void ifthen(bool cond, lazy void dg)
>> {
>>      if (cond)
>>          dg();
>> }
>
> int foo(int x){
>     ifthen(!x, return 2); // uh oh
>     return 3;
> }

On 11/17/2013 2:38 AM, Jacob Carlborg wrote:
> On 2013-11-17 10:00, Walter Bright wrote:
>
>> That would be better, but I don't think enough better.
>
> Then why to we have UDA's with the same syntax as language attributes and why do
> we have operator overloading.
>
> You can hide arbitrary code behind operator overloading.

1. I don't believe we can decide on language features by analogy. D is complex enough that one can use analogy to justify anything.

2. You cannot do anything behind a function call - the 'return' discussed earlier, and async/await for another, i.e. operator overloading cannot introduce control flow, cannot introduce variables into the current scope, etc.

On 11/17/2013 11:41 AM, Simen Kjærås wrote:
>
> Source is attached. I hope God forgives me.
>

I suppose you'd have to do something like

x.Where(OR( NOT(Args.thing = "thing"), Args.sing = "sing"))

for nesting and negation and all that.

I'd wait for walter to relax the restrictions on ==, &&, etc operator overloading. Then you probably could do

x.Where(X => X.thing != "thing" || X.sing == "sing")

let's see here. If X's type is QueryExp!Entity and the return type is SomeRange!Entity then querying looks doable.

how about composing expressions? take the result of that lambda EXP,
EXP = EXP && X.cling == 1; // should work fine?

how about decomposing expressions?
EXP = EXP.lhs; // should work fine?

EXP.rhs.rhs.value // returns "sing" - should work fine? the lambda should create a closure, so we should be able to get out any value we put in

you won't be able to do

x.Where(X => upper(X.thing) == "THING")

without ast macros but will have to be satisfied with

x.Where(X => X.thing.upper() == "THING")

will you be able to do

x.Where(X => X.thing == "THING" && x.Any(X2 => X2.thing == X.thing && X2.id != X.id))

?

either "Any" would have to be only for template expressions, or X would have to be an outer context like so:

x.Where(X => X.it.thing == "THING" && X.x.Any(X2 => X2.it.thing == X.it.thing && X2.it.id != X.it.id))

because x.Any(...) should return bool, but inside the query expression it should return QueryExp. In both cases it would take a param of

QueryExp delegate(QueryExp)

Anybody else have any other ideas?