January 25, 2013
On Fri, 25 Jan 2013 02:57:22 +0100
"Adam D. Ruppe" <destructionator@gmail.com> wrote:

> On Friday, 25 January 2013 at 01:54:03 UTC, Nick Sabalausky wrote:
> > Sorry about that. I'm just frustrated at fighting another uphill D battle against those who have far, far more pull than I do, and are every bit as difficult to sway as I am ;).
> 
> I literally screamed at my computer screen a couple times in this thread. This is an argument we've been having for years and I've gotta say, I'm kinda fed up with it.
> 

Getting screamed at and just taking it, without ever giving me crap back about it, is one of the top killer features of electronics technology. It's like a squeezy stress ball, except it's always handy when you need it...Probably because it's usually also the cause, but hey.

> But I feel like we're finding common ground this time, where we weren't able to the last several times.

Maybe because we're *all* finally tired of arguing about it ;)

January 25, 2013
On Thursday, January 24, 2013 21:24:05 Andrei Alexandrescu wrote:
> On 1/24/13 9:11 PM, Jonathan M Davis wrote:
> > I believe that that's what we have now. The problem is when you want a
> > property which returns a delegate. And for that, we need @property.
> > Getting
> > rid of @property makes it a problem, whereas with @property, it can work -
> > as can property functions which return delegates.
> 
> Well how about we just renounce those for the sake of simplification.

Without explicit properties you can't switch back and forth between something being a property function and a variable - which is one of the main points of properties in the first place. With explicit properties, it's possible.

Also, I think that there's real value from an API perspective to mark what is and isn't intended to be used as a property.

- Jonathan M Davis
January 25, 2013
On Thursday, 24 January 2013 at 18:05:25 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 9:47 AM, Artur Skawina wrote:
>> Having ()-less function calls is just insane; if it isn't obvious to you why,
>> you just haven't read enough code that (ab)uses them.
>
> You see, this is the kind of argument that I find very damaging to the conversation. It lacks any shred of material evidence, evokes emotion, manipulates the reader's opinion (framing them into incompetent/inexperienced if they disagree), and implies an appeal to authority. Please don't do that anymore.
>

Let me rephrase that in a proper way.

Functional style is very painful right now. Function you pass as argument are executed implicitly, function as variable don't behave like native ones, and with the new proposal, it add confusion on the function returned.

It is kind of dumb that D do not promote functional style as it has shown to solve many problems that arise right now.
January 25, 2013
On Thursday, 24 January 2013 at 18:35:08 UTC, mist wrote:
> Yes, I am able to use parens, but in _my_ code I also do not need -property or anything - I am C++ programmer after all, I can discipline myself to certain code style even without compiler help. But writing generic code and reading one of others... I am glad I have not had to do any high-order function generic processing yet.

I always create dumb lambda to do so as going fully functional is too painful map!(a => foo(a)) instead of map!foo . That is really annoying.
January 25, 2013
On 01/25/2013 03:44 AM, deadalnix wrote:
> On Thursday, 24 January 2013 at 18:05:25 UTC, Andrei Alexandrescu wrote:
>> On 1/24/13 9:47 AM, Artur Skawina wrote:
>>> Having ()-less function calls is just insane; if it isn't obvious to
>>> you why,
>>> you just haven't read enough code that (ab)uses them.
>>
>> You see, this is the kind of argument that I find very damaging to the
>> conversation. It lacks any shred of material evidence, evokes emotion,
>> manipulates the reader's opinion (framing them into
>> incompetent/inexperienced if they disagree), and implies an appeal to
>> authority. Please don't do that anymore.
>>
>
> Let me rephrase that in a proper way.
>
> Functional style is very painful right now. Function you pass as
> argument are executed implicitly, function as variable don't behave like
> native ones, and with the new proposal, it add confusion on the function
> returned.
>
> It is kind of dumb that D do not promote functional style as it has
> shown to solve many problems that arise right now.

The main issue is horrible garbage collector performance for many small allocations. Syntactically we could do what scala does:

scala> def fun()=2
fun: ()Int

scala> fun : Int
res0: Int = 2

scala> fun : (()=>Int)
res1: () => Int = <function0>

January 25, 2013
On Thu, 24 Jan 2013 18:00:06 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/13 7:36 PM, Adam Wilson wrote:
>> Also non-logical special case rules like this make the language harder
>> to learn, therefore harder to evangelize.
>
> Definitely. But it shouldn't be forgotten that syntactic warts are also a liability.
>
> Andrei
>
>

I would argue that given how common they already are, cost of the wart is far smaller than the benefit of not having the unique-to-D special case that makes the language that much harder to learn.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
January 25, 2013
2013/1/25 deadalnix <deadalnix@gmail.com>

> Functional style is very painful right now. Function you pass as argument are executed implicitly, function as variable don't behave like native ones, and with the new proposal, it add confusion on the function returned.
>

I'd like to add a rule which forgotten to mention about optional parentheses for normal functions.

> 1. Optional parentheses for normal functions should work shallowly IMO.
1a. Optional parentheses for normal functions is just allowed for the getter usage.

int foo();
foo(); // ok
foo; // ok,  from #1

void bar(int);
bar(1); // ok
bar = 1;  // disallowed, from #1a

Kenji Hara


January 25, 2013
On 01/25/2013 03:48 AM, deadalnix wrote:
> On Thursday, 24 January 2013 at 18:35:08 UTC, mist wrote:
>> Yes, I am able to use parens, but in _my_ code I also do not need
>> -property or anything - I am C++ programmer after all, I can
>> discipline myself to certain code style even without compiler help.
>> But writing generic code and reading one of others... I am glad I have
>> not had to do any high-order function generic processing yet.
>
> I always create dumb lambda to do so as going fully functional is too
> painful map!(a => foo(a)) instead of map!foo . That is really annoying.

And just as pointless.
January 25, 2013
Nick Treleaven wrote:

> write!"%s\n" = someExpression;

Iff at all I prefer `write!someExpression= "%s\n";'

Seriously, checking validity at execution time causes another sort of hiccoughs that should not be part of a language intended for large scale coding.

-manfred

January 25, 2013
On Friday, January 25, 2013 11:09:15 kenji hara wrote:
>    That is more serious than (a). If we adopt this rule, we will *really*
> get lost the way to distinguish property functions and raw data fields.
> (Note that: In current typeof(foo) already returns int. So AddressExp is
> only one way to getting (normal|property) function information by its
> type.) From the view of meta-programming, I think this makes a serious flaw.

We could add a __trait which detected whether a field was an actual variable or not.

- Jonathan M Davis