On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
> On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
>> I agree with you but Walter is very afraid of breaking code.
>
> The history of what happens when D code breaks because of language changes is not a happy one.

That is why semantic needs to be clean. Semy hacky stuff ends up causing trouble and we either have to live with it or break code.

Philippe Sigaud wrote:

> cwritefln!"For sample

Cough! `cfln' would eliminate the five letters `write'. For which purpose are they needed?

Seriously, without some guarentee that `!"' starts a compile time checked string---and a defined metalanguage for describing compile time checking of compile time checked strings---close to every coding project will become an unmaintanable mess of DSL implementations "on the fly".

The code you supplied on pages 170 to 171 is a good example for this forsight: please declare how much time an average member of an intended group of maintenance coders will need to grab the content of your idea. And of course declare the minimal skills all members of this group must have.

-manfred

On 1/24/13 9:54 PM, Adam Wilson wrote:
> 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.

Again, the question needs asking: is it a given that we need to allow optional parentheses? Otherwise we'll keep on rehashing this over and over again.

Andrei

On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 3:58 PM, mist wrote:
>> Really, all this backwards-compatibility talk is a crap.
>
> There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to.
>

If you or Walter think that D is somehow stable or backward compatible, you must both be very high on drugs. Yes that is an ad hominem.

Let me tell you a story. This story take place one month ago. A guy (me) get the news released version of the compiler. After all, he badly needs it as bugs in the previous cause the GC to misbehave in very scary ways.

First, some language specs have changed, so his code is broken. But hey, that is to be expected and so the guy fix his code. A bug is discovered in the compiler, it is a regression, and it make the guy's code, once fixed, impossible to compile with 2.061 AT ALL.

Hopefully a brave knight (Kenji) cam to fight the monstrous compiler and finally get it to compile the code it should have compiled from day 1. The guy now use a custom patched version of the compiler.

No revision of the compiler is released at this point, but worse, the guy's code now trigger some other bugs into 2.061 (but not in his patched version). The guy can't do D on his mac anymore as he have no clue how to do the setup for his patched compiler. After all, he is not really an apple guy.

Note that  was already using a custom compiler before 2.060 as 2.059 already have blocking bugs for me.

D is nothing even remotely close to stable. D introduce breaking change with EVERY new release. Worse, D has no sane way to introduce such breaking change in a sane way. And suddenly, this is an issue ?

On Friday, January 25, 2013 03:38:20 Jonathan M Davis wrote:
> 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.

And actually, something far more important than any of those reasons is the issue of setters. We've focused most of this discussion on optional parens and the situation with getter properties, but setter properties and their issues are also important. Would you want code like this to compile?

range.popFront = 17;
container.linearRemove = range;
path.baseName = ".xyz";
str.icmp = "hello";
enforce(a == b) = "msg";
arr.sameHead = arr2;

With @property, we can restrict the functions which can be used with the setter syntax to functions where that makes sense. Without it, all kinds of ridiculous code like the code above would be allowed.

Allowing optional parens is one thing, but conflating that with properties is something else entirely. Property functions are not just functions which are called without parens, and we shouldn't act like they are.

- Jonathan M Davis

On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu wrote:
> Again, the question needs asking: is it a given that we need to allow optional parentheses? Otherwise we'll keep on rehashing this over and over again.

I hate optional parentheses with a passion, but I think that it's quite clear that too many people want them (including many who want @property) and that too much code will break if we make the change. I think that we can reach a consensus on how @property should function, but we'll never get a consensus that optional parentheses should be done away with.

So, yes. I think that we can move forward with the assumption that optional parens are here to stay (much as I don't personally like that).

- Jonathan M Davis

2013/1/25 Jonathan M Davis <jmdavisProg@gmx.com>

> 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.


OK, let's think.

When a property function exists:
@property int foo();

#1 Only check whether it is a property function or not.
static assert(__traits(isProperty, foo) == true);
Pros: We can get minimum information.
Cons: We cannot check whether the foo is other function attributes: pure,
nothrow, @safe.

#2 Returns a type from __traits.
static assert(__traits(getPropertyType, foo).stringof == "@property int()");
Pros: We can access all information about property function.
Cons: __traits() is parsed as an expression, so we cannot use it as a type
directly.
   __traits(getPropertyType, foo)* fp; // declaring function pointer
   Instead, some template should be required.
   TypeTuple!(__traits(getPropertyType, foo))[0]* fp;

#3 Adding a special case in CastExpression
auto fp = &foo;    // Not allowed, because property function foo returns an
rvalue.
auto fp = cast(function)&foo;   //New, Gets a function pointer of foo
Pros1: Can access fully information of foo from typeof(fp).
Pros2: We can call a property function indirectly through function pointer.
Pros3: Newly syntax and semantics has no conflict with existings.
Cons: cast(function) and cast(delegete) necessary.

#4 An extension from #3
auto p = cast(@property)&foo;  // p is a function pointer.
auto p = cast(@property)&s.foo;  // p is a delegate.
Pros: Only one new syntax is necessary.
Cons: Ugly...

---

In basic, I don't like adding new __traits for this purpose, like #1 and #2. In the compile world of D, a function type is already a first class object to carry the information related function. Similarly, function pointer and delegate are widely used as a runtime container to make runtime bindings to function symbols.
>From these facts, creating an escape hatch from property function to normal
function type/pointer is enough worthwhile to me. It makes it possible to reuse a number of meta-programming operations for normal function/function type/function pointers.

#3 and #4 are comes from an existing feature, which picking up one from
overloaded functions by CastExpression.
void foo() {}
void foo(int) {}
auto fp = cast(void function())&foo;
// fp is equal to the address of first foo.

So, I prefer adding newly meanings to CastExp.

Kenji Hara

2013/1/25 Jonathan M Davis <jmdavisProg@gmx.com>

> And actually, something far more important than any of those reasons is the
> issue of setters. We've focused most of this discussion on optional parens
> and
> the situation with getter properties, but setter properties and their
> issues
> are also important. Would you want code like this to compile?
>
> range.popFront = 17;
> container.linearRemove = range;
> path.baseName = ".xyz";
> str.icmp = "hello";
> enforce(a == b) = "msg";
> arr.sameHead = arr2;
>
> With @property, we can restrict the functions which can be used with the setter syntax to functions where that makes sense. Without it, all kinds of ridiculous code like the code above would be allowed.
>
> Allowing optional parens is one thing, but conflating that with properties
> is
> something else entirely. Property functions are not just functions which
> are
> called without parens, and we shouldn't act like they are.


I have explained an additional rule in #1a.

> 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

 If based on that, such situations which you are worried will not occur.

Kenji Hara

On Friday, January 25, 2013 13:47:31 kenji hara wrote:
> 2013/1/25 Jonathan M Davis <jmdavisProg@gmx.com>
> 
> > And actually, something far more important than any of those reasons is
> > the
> > issue of setters. We've focused most of this discussion on optional parens
> > and
> > the situation with getter properties, but setter properties and their
> > issues
> > are also important. Would you want code like this to compile?
> > 
> > range.popFront = 17;
> > container.linearRemove = range;
> > path.baseName = ".xyz";
> > str.icmp = "hello";
> > enforce(a == b) = "msg";
> > arr.sameHead = arr2;
> > 
> > With @property, we can restrict the functions which can be used with the
> > setter syntax to functions where that makes sense. Without it, all kinds
> > of
> > ridiculous code like the code above would be allowed.
> > 
> > Allowing optional parens is one thing, but conflating that with properties
> > is
> > something else entirely. Property functions are not just functions which
> > are
> > called without parens, and we shouldn't act like they are.
> 
> I have explained an additional rule in #1a.

I know, and I agree with it. But Andrei is pushing for removing @property entirely and looking for arguments to keep it. And IMHO, the issue of how setters are handled is an extremely good reason to keep @property.

- Jonathan M Davis

On Friday, 25 January 2013 at 00:55:54 UTC, kenji hara wrote:
> I can imagine a situation that we might not want to treat property
> functions as DATAs simply.
>
> If you have a struct which have some property functions as members, and
> you'd want to serialize it:
>
> struct S {
>    int value_;
>    @property int value() { return value_; }
> }
>
> At least, the serialization library should recognize the S.value is a
> _property function_, not a int DATA.
>
> In most case, property functions should be treated as a simple DATA field.
> but in a few case, it shouldn't. I have thought AddressExpression &func is
> one of the places.
>
> Related bugzilla issue I posted:
> http://d.puremagic.com/issues/show_bug.cgi?id=9062
>

Indeed ! @property should be different as far as reflection is involved. For usage, it shouldn't make any difference.