On 24/01/2013 17:04, Philippe Sigaud wrote:
> On Thu, Jan 24, 2013 at 4:53 PM, Nick Treleaven
> <ntrel-public@yahoo.co.uk> wrote:
>
>> write!"%s\n" = someExpression;
>>
>> :-p
>>
>> Seriously, it would be nice to have a compile-time checked format string for
>> writefln.
>
> I made a stab at it in a template tutorial that can be found on github:
>
> https://github.com/PhilippeSigaud/D-templates-tutorial
>
> You can grab the pdf, it's on section 5.11, p. 168 (Statically-Checked Writeln)
>
> Use example:
>
> cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo", 3.14);

Yes, I wish that was in Phobos ;-)

In fact, couldn't cwritefln just be a template overload of writefln? The string value parameter may be enough to distinguish it from the runtime version.

On 2013-01-25 14:26, mist wrote:

> Hm, shouldn't it be processed like that:
> 1) evaluate "f = 3", setter called
> 2) evaluate "(f = 3)" -> evaluate "f" -> getter called
> 3) evaluate "auto i = ", setter called
> ?

Yes, but why would a setter be called at step 3?

-- 
/Jacob Carlborg

On Friday, 25 January 2013 at 13:52:37 UTC, Jacob Carlborg wrote:
> On 2013-01-25 14:26, mist wrote:
>
>> Hm, shouldn't it be processed like that:
>> 1) evaluate "f = 3", setter called
>> 2) evaluate "(f = 3)" -> evaluate "f" -> getter called
>> 3) evaluate "auto i = ", setter called
>> ?
>
> Yes, but why would a setter be called at step 3?

Was thinking about i setter, did not pay attention it is actually a new declaration :) Never mind.

On 1/25/13 4:49 AM, Don wrote:
> 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.
>
> I don't believe that is true. Remember when 'bit' was removed from the
> language?
> It didn't cause any complaints at all.
>
> This attitude is very harmful. Our real problem is that we're not making
> promises about what we won't change. When we haven't made such promises,
> we then become fearful of changing *anything*.
> Then we bend over backwards to avoid changing things that actually
> nobody cares about. This is a recipe for locking bugs into the language
> forever.
>
> Instead, we should be trying to continuously expand the things we
> guarantee will continue to work. Ideally we would be precise about the
> things that are likely to change, and which we don't currently guarantee.

TDPL did exactly that. For example it doesn't mention foreach_reverse or lazy. Far as I know that didn't make a difference.

Andrei

On Friday, 25 January 2013 at 10:56:14 UTC, mist wrote:
> On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
>> module abc;
>> @property int foo(int n);
>>
>> void main() {
>>  foo = 1;  // top-level property setter
>>  1.foo;  // property getter with UFCS
>> }
>>
>> We cannot distinguish the two usages without adding any new features.
>>
>> Kenji Hara
>
> "1.foo" must be compile error here. Makes as much sense as
>
> int a;
> void main() {
>     1.a;
> }
>
> Property must behave exactly like data or it is not a property.

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.

On Friday, 25 January 2013 at 14:18:06 UTC, Andrei Alexandrescu wrote:
> TDPL did exactly that. For example it doesn't mention foreach_reverse or lazy. Far as I know that didn't make a difference.
>

Wise move !

On 1/25/13 5:56 AM, Artur Skawina wrote:
> On 01/25/13 08:39, Andrei Alexandrescu wrote:
>> On 1/25/13 2:12 AM, Artur Skawina wrote:
>>> On 01/24/13 21:13, Andrei Alexandrescu wrote:
>>>> On 1/24/13 2:03 PM, Artur Skawina wrote:
>>>>> Trying to make arguments you don't like go away and silencing the messenger
>>>>> is your MO.
>>>>
>>>> Now that's what's called "ad hominem".
>>>
>>> No, it's not - it's just stating the facts; this was not the first such incident.
>>
>> Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.
>
> Hmm, I can see how you could view this as an ad hominem, given that definition,

How can that be seen as anything else? What definition do you have?

You made a mistake under the heat of the argument. We all do. Don't try to explain how actually you didn't. The right course is to casually apologize and move on.

> but it's not meant to be one and actually isn't - it has no bearing on
> the @property nor ()-less calls issues; this is just about the process.
>
> Remember how you originally replied to my message, after removing everything
> but one sentence, which was clearly both a summary of my subjective position
> and deliberately phrased in a way to encourage at least some consideration wrt
> $subject by others making a decision.

I kept the sentence that I had a reply for. The rest I understood and agreed with.


Andrei

On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
> ... But I don't see why should that matter.

But I don't see why that should matter.

...aced it.

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.

On Friday, 25 January 2013 at 14:29:22 UTC, mist wrote:
>
> 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.

My understanding of the point of UFCS has been that it enables you to add functionality to a type without actually modifying the type. So, let me get this straight... are you saying that the following code snippet breaks property semantics?

struct MyType {}

@property bool is_valid(MyType)
{
    return true;
}

void main()
{
    MyType mt;
    mt.is_valid;
}

Or, are you saying that we shouldn't be able to add properties to built-in types? Or are you saying something else entirely?