On Friday, 25 January 2013 at 16:48:21 UTC, Simen Kjaeraas wrote:
> On 2013-37-25 17:01, eles <eles@eles.com> wrote:
>
>> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> But setting the hours field to 28 is natural? While I want all
> properties to be safe nothrow pure, it is unlikely to be a good
> idea to force this upon people.
>
> I'm all for putting it in the style guide, though.

See this answer here: http://forum.dlang.org/post/mdhvjbjqryzjljzqleay@forum.dlang.org

The problem is that programmers would start feeling like "it's better" to check every assignment for exceptions, in the case that the variable is latter converted into a throwing property.

I have no solution to that, though...

OOH, I feel it will lead to bad programming style. OTOH, I feel like masking a database interrogation behind a property will throw some exception sooner or later.

So, I am clueless.

On Fri, 25 Jan 2013 15:29:21 +0100
"mist" <none@none.none> wrote:

> On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
> > I don't see 1.foo the way you see it. I see it like this:
> >
> > @property bool is_zero(X value)
> > {
> >     return value == 0;
> > }
> >
> > void main()
> > {
> >     X value;
> >     value.is_zero;
> > }
> >
> > It's just that X happens to be a built-in type, instead of a user-defined type. But I don't see why should that matter.
> 
> It is a tempting attempt to save two symbols of typing that
> completely breaks property semantics. I am objecting against it.
> With all my passion.
> Use value.is_zero() for UFCS magic.

I think you might have misunderstood it. What he's trying to do is use UFCS to add a property to a type instead of adding a function.

On Friday, January 25, 2013 20:41:01 eles wrote:

> You are right. In fact, just after I post the message, I was hit by second toughts.
> 
> But a issue still remains: assignments of variables are not usually checked for exceptions. Programmers do not have in mind that they could trigger exceptions.
> 
> However, properties could do.
> 
> The danger that I see is that programmers will start to "preventively" check everything for exceptions, "just in case" that those current variable assignments would be latter turned into properties.
> 
> Do you feel like embracing all your code in try/catch?

Except that variable assignments _can_ throw, because opAssign could throw. It's true that replacing a variable with a property function which checks its arguments would likely add a new exception to catch, but there's really no way around that. But if the property function checks for stuff which was supposed to be valid before, you changed the semantics anyway, which could be done in a variety of other ways (e.g. making the property function multiply the argument by 7). The reality of the matter is that a property function _isn't_ a variable, just like an overloaded operator isn't the same as using that operator on a built-in type. And the issues are pretty much the same as they are with overloaded operators. But what should be done with try-catch blocks depends on what the code's doing, and if you're having to litter your code with them, you're probably doing something wrong anyway. Still, the possible breakage caused by replacing a variable with a property function which throws is the sort of thing that needs to be considered when making that change.

- Jonathan m Davis

On Fri, Jan 25, 2013 at 4:47 AM, Manfred Nowak <svv1999@hotmail.com> wrote:
> Philippe Sigaud wrote:
>
>> cwritefln!"For sample
>
> Cough! `cfln' would eliminate the five letters `write'. For which purpose are they needed?

:)

Yes, I agree.


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

Well, the string-formatting DSL is well known. I don't think someone would be that distressed by its use.

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

Such hate... Keep cool and please give us your own code and preferred solution to compile-time formatting string checking.

On 1/25/13 12:17 PM, Rob T wrote:
> On Friday, 25 January 2013 at 16:43:45 UTC, Jesse Phillips wrote:
> [...]
>> That said many that want @property, want optional parens to die, as
>> shown by your side comment that follows.
>>
>
> I think that observation pins the whole debate down, and it's an
> incredible amount of debate for something that boils down little more
> than personal taste. We don't even need property-like behavior, it's not
> that important. Meanwhile really serious problems exist that are not
> being attended to.
>
> The concept of a property works perfectly fine without explicit
> @property enforcement (except for perhaps an edge case or two that can
> be corrected). When I started with D, the TDPL told me that I had to put
> @property in, and it was actually a relief to discover that I did not
> have to do that. It's a waste of time, and more than half the time I
> could not decide if I wanted property-like behavior or not, so the lack
> of enforcement was a plus for me.
>
> If the default behavior is optional parens plus no @property
> enforcement, i.e., the current behavior, then for the people who want to
> change the default behavior need to specify @property and we implement
> enforcement for those situations. However, for the remaining functions,
> the property behavior is optional and not enforced, so some means such
> as the @function proposal will be needed to enforce the traditional
> c-like function call syntax.
>
> But is there any real need for the extra complications of implementing
> property and c-style function call enforcement? This is D and there's no
> law that states that D must behave exactly like C.
>
> I think Walters proposal to shoot @property is perfectly sound. Get rid
> of it, fix the edge cases, and move on to solving the problems that
> matter a whole lot more than this one.
>
> If Walter's proposal is not sound, then we need real clear technical
> reasons why enforcement is required, as opposed to arguments that boil
> down to personal tastes.

I agree with all of the above. There has been a fair amount of rationalization and appeal to emotion on all sides. It would be great to get back to reason and clearly compartmentalize objective arguments (of which there have been a few very profound ones) and personal preference.

On the objective side there are a few challenges that have been well discussed:

1. Syntactic and semantic implications of properties that return callable entities

2. Introspection, how does one distinguish between a genuine field and a property when necessary

3. Impact on existing and future code

On the subjective side, Walter's and my opinion and experience have been largely aligned. With that in mind but speaking for myself unless otherwise noted, here are some bits of my subjective opinion:

1. In C and C++ the syntax "func" or "object.method" does nothing interesting or useful. In C, "func" is actually equivalent with "&func". In C it's actually worse, "func" yields the type "reference to function" which is highly restricted and obeys some rather arcane rules (in particular it's implicitly convertible to pointer to function).

C has no methods so the syntax "object.method" does not apply to it. In C++, "object.method" is probably the oddest construct in the entire language: it returns a type that exists but has no name, is not expressible syntactically, is not first class (one can't assign "object.method" to a variable), and has only two allowed operations: take address or apply the function call operator "()". Various C++ implementations have extensions that fix this.

Both Walter and I consider these serious lapses in language design. Two of the most accessible elements of syntax do things of considerably low interest and use. I hope I now clarified why I have a dim view of arguments that - implicitly or explicitly - assume the C or C++ behavior in this area is an example to follow on technical grounds. (Clearly, familiarity is a much better argument.)

2. I have tried to add @property appropriately in Phobos, in particular for ranges:

struct SomeRange {
  @property bool empty();
  @property ref T front();
  void popFront();
}

There's more "@property" to be seen with "save" and "back". Subjectively that just didn't work well for me. It adds clutter to an otherwise simple and straightforward API, and penalizes usage for benefits that I could never reap. I understand how some people are glad to put that in everywhere, and find meaning in requiring parens with popFront and popBack but not the others. Yet for me it was liberating (see 1 above too) I could just write "r.popFront" without the parens and have it do its deed. It is the right semantics for a simple syntax.

3. Whatever we do going forward should be _simple_ but not _simplistic_. Right now it's easy to forget that we're all close to the subject. We have it in working memory (at least it's what I think about all the time) and any incremental complexity is an easy cost to absorb intellectually.

But when we need to teach this to newcomers or even approach it again with a "cold cache", any undue complexity will be jarring.

4. Whether we like it or not, backward compatibility is an issue. The parens or no parens aspect upon a function call is too ubiquitous to write off as an obscure circumstance. So I don't think the obscurity argument applies.

Granted, there are several ways to approach the compatibility issue, all with their specific tradeoffs. All I'm saying is that careful considerations of compatibility must be integral to whatever we do about this.

5. This is a matter in which reasonable people may disagree. For better or worse Walter and to a lesser extent myself are in the position to decide. We're doing the best to gather, mind, and integrate opinions and suggestions but clearly no decision that would please everyone. So please bear with us. I understand this may be frustrating but the best we all can do is think beyond our own preference and on behalf of the larger community.


Thanks,

Andrei

On Friday, 25 January 2013 at 19:50:23 UTC, eles wrote:
> On Friday, 25 January 2013 at 16:48:21 UTC, Simen Kjaeraas wrote:
>> On 2013-37-25 17:01, eles <eles@eles.com> wrote:
>>
>>> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> But setting the hours field to 28 is natural? While I want all
>> properties to be safe nothrow pure, it is unlikely to be a good
>> idea to force this upon people.
>>
>> I'm all for putting it in the style guide, though.
>
> See this answer here: http://forum.dlang.org/post/mdhvjbjqryzjljzqleay@forum.dlang.org
>
> The problem is that programmers would start feeling like "it's better" to check every assignment for exceptions, in the case that the variable is latter converted into a throwing property.
>
> I have no solution to that, though...
>
> OOH, I feel it will lead to bad programming style. OTOH, I feel like masking a database interrogation behind a property will throw some exception sooner or later.
>
> So, I am clueless.

You can easily wrap all of your functions in a try catch block that will act as a safety net and catch all potential Exception throws.

Unfortunately I don't know if there's a performance hit with wrapping up all functions in this way.

--rt

On Friday, 25 January 2013 at 19:54:29 UTC, Nick Sabalausky wrote:
> I think you might have misunderstood it. What he's trying to do is use
> UFCS to add a property to a type instead of adding a function.

I got it. What I am questioning is that allowing this in some way is a must. And somewhat changed my mind after that :) There is semantic ambiguity here currently (rules are too lax) that I have described in wiki http://wiki.dlang.org/Property_Discussion_Wrap-up - and I pretty much like proposal there.

Am Fri, 25 Jan 2013 10:39:50 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:


> - It's illegal to mark a function that takes 2 or more arguments as
>   @property, because it makes no sense.
> 

3 or more arguments. UFCS properties have 2 arguments:

@property void age(Person p, int value); //OK, bad example, but you
get the idea

Finally, stating some opinions clearly.
Thank you.

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

What really got me upset about it was that here we have one of my favorite modern language features, properties, and then all of a sudden *both* the top #1 and #2 people behind D start trying to gut it if not outright remove it from the language entirely, instead of enacting, or at least promising to *eventually* enact, the long overdue fixes I've been anxiously awaiting.