On Wednesday, 12 December 2018 at 20:12:54 UTC, Guillaume Piolat wrote:
> On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves wrote:
>> On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
>>> On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote:
>>>> One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name.  (10 years ago I would be in the other camp)
>>>
>>> Can you please explain it in more detail? I never read such about getters and setters.
>>
>> Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html
>
> Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter
>
> if you like more pompous names.

Law of Demeter is different. Law of Demeter basically translates to "don't have more than one dot", like x.y() is fine, x.y.z() isn't because it makes too many assumptions about internals of x and y.

Properties have use when the setting or getting the variable isn't a trivial assignment. For example, sometimes the units need to be converted along the way. In many cases, especially when GUI programming, you might want to do additional actions when settings/getting a variable, like calling listeners to notify them of the value change so that they can change the value in the GUI widget automatically.

On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- announce wrote:
> On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
> > @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
>
> Imagine you have void delegate() prop() and use the property
> without parentheses everywhere then suddenly m.prop() doesn't
> call the delegate. So it's mostly for getters and should be used
> only in edge cases, most code should be fine with optional parens.

Except that @property does not currently have any effect on this. The delegate case (or really, the case of callables in general) is one argument for keeping @property for using in that particular corner case, since without it, having property functions that return callables simply doesn't work, but @property has never been made to actually handle that case, so having property functions that return callables has never worked in D. It's certainly been discussed before, but the implementation has never been changed to make it work. If/when we finally rework @property, that use case would be the number one reason to not simply get rid of @property, but until then, it doesn't actually fix that use case. As things stand, @property basically just serves as documentation of intent for the API and as a way to screw up type introspection by having the compiler lie about the type of the property.

> >I think there’s a general consensus that @safe, pure and immutable should be default.
>
> I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus.

There are definitely people who want one or more of those attributes as the default, but I very much doubt that it's a consensus. It wouldn't surprise me if @safe or pure by default went over fairly well, but I'm sure that immutable or const by default would be far more controversial, because that's a big shift from what C-derived languages normally do. Personally, I would be very unhappy if it were the default, though I know that there are some folks who would very much like to see const or immutable be the default.

> >I’ve lost count now of how many times I’ve had to write @safe @nogc pure nothrow const scope return. Really.
>
> If immutable was default, wouldn't you still need to write const attribute everywhere, and @nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.

If immutable were the default, then I expect that writing types that worked with immutable would become more common, because it would then be encouraged by the language, but I think that your average type is written to work as mutable (and maybe const), and it's a pretty big shift to write types to be immutable unless you're talking about simple POD types, so if immutable became the default, I expect that mutable (or whatever the modifier to make a type mutable would be) would start getting plastered everywhere. And without the range API being changed, ranges wouldn't work unless you marked them as mutable, making const or immutable by default a bit of a mess for what would now be idiomatic D code (though if the default were changed to const or immutable, we'd probably see the range API be changed to use the classic, functional head/tail list mechanism rather than front and popFront, which could very well be an improvement anyway).

- Jonathan M Davis

On Wed, Dec 12, 2018 at 02:10:31PM -0700, Jonathan M Davis via Digitalmars-d-announce wrote:
> On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- announce wrote:
[...]
> > Imagine you have void delegate() prop() and use the property
> > without parentheses everywhere then suddenly m.prop() doesn't
> > call the delegate. So it's mostly for getters and should be used
> > only in edge cases, most code should be fine with optional parens.
> 
> Except that @property does not currently have any effect on this. The delegate case (or really, the case of callables in general) is one argument for keeping @property for using in that particular corner case, since without it, having property functions that return callables simply doesn't work, but @property has never been made to actually handle that case, so having property functions that return callables has never worked in D. It's certainly been discussed before, but the implementation has never been changed to make it work.

Yep. Basically, @property as currently implemented is useless, and I've stopped bothering with it except where Phobos requires it.


> If/when we finally rework @property, that use case would be the number one reason to not simply get rid of @property, but until then, it doesn't actually fix that use case. As things stand, @property basically just serves as documentation of intent for the API and as a way to screw up type introspection by having the compiler lie about the type of the property.
[...]

Haha yeah, currently @property confers no real benefits and only comes with bad (and probably unexpected) side-effects.  More confirmation that it's a waste of time and not worth my attention.

If the delegate property thing is the only real use case for @property, it seems quite out-of-proportion that an entire @-identifier in the language is dedicated just for this purpose. One would've thought D ought to be better designed than this...


T

-- 
Gone Chopin. Bach in a minuet.

On Wednesday, December 12, 2018 3:49:51 PM MST H. S. Teoh via Digitalmars-d- announce wrote:
> If the delegate property thing is the only real use case for @property, it seems quite out-of-proportion that an entire @-identifier in the language is dedicated just for this purpose. One would've thought D ought to be better designed than this...

Originally, the idea was to restrict property syntax to functions marked with @property, which would mean no more lax parens. If it's a property function, then it must be called like one, and if it's not, then it must be called as a function (i.e. with parens), whereas right now, we have this mess where folks can use parens or not however they feel like. That doesn't work well with being able to swap between property functions and public variables, and it makes generic code harder, because in general, you can't rely on whether something is called with parens or not, meaning that the symbol in question has to be an actual function (where parens are optional) instead of being allowed to be a different kind of callable (which requires parens) or be a variable (which can't have parens). @property would have fixed all of that by forcing functions to either be called with or without parens based on what they're used for, allowing generic code to rely on more than convention ensuring that symbols are called consistently with or without parens (and thus allow symbols other than functions to be reliably used in place of functions where appropriate). So, as originally envisioned, @property was anything but useless.

However, all of that became extremely unpopular once UFCS became a thing, because most folks didn't like having an empty set of parens when calling a templated function that had a template argument that used parens, and as such, they wanted to be able to continue to drop the parens, which goes against the core idea behind @property. So, the end result is that the original plans for @property got dropped, and plenty of folks would be very unhappy if we went in that direction now - but it's still the case that @property was supposed to solve a very real problem, and that problem remains unsolved.

As things stand, you have to be _very_ careful when using anything other than a function in a generic context that normally uses a function, because there's no guarantee that using something other than a function will work due to the lack of guarantee of whether parens will be used or not. It tends to work better with variables than with callables, because dropping parens is so popular, and callables aren't, but it's still a problem. Anyone who wants to use a callable instead of a function in generic code is almost certainly in for a world of hurt unless they're in control of all of the code involved - and that's without even getting into the issue of property functions that return callables (those simply don't work at all).

Template constraints combat this to an extent in that they end up requiring that the construct in question either be callable with parens or usable without them, but that places no restrictions on the code that actually uses the symbols, making it easy for code to use parens when it shouldn't or not use parens when it should and then run into problems when it's given a type that conforms to the template constraint, but the code didn't use the symbol in the same way as the constraint. The only thing things that really prevent this from be a much bigger problem than it is is that many folks do follow the conventions set forth by the template constraint (e.g. always calling front without parens) and the fact that in most cases, it's the lack of parens which is required, and using variables instead of functions is far more popular than using callables instead of functions. So, convention is really all that prevents this from being a bigger problem, and the end result is that callables in generic code are borderline useless.

On example of trying to work around this problem is that not all that long ago, isInputRange was actually changed to use popFront without parens just so that folks could rely on being able to call it without parens, since previously it was possible to use a delegate or other callable for popFront instead of a function, which would then not have worked with any code where folks didn't bother to put parens on popFront when calling it.

All in all though, I think that the fact that we aren't strict about parens usage mostly kills the use of callables in generic code except in cases where you're in control of all of the code involved. It could be argued that callables are desirable infrequently enough that being able to drop parens when calling functions for whatever syntactic beauty supposedly comes with outweighs the loss, but that doesn't mean that the problem isn't there, just that many folks don't care and think that the tradeoff is worth it.

- Jonathan M Davis

On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> A few things that have annoyed me about writing D lately:
>
> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/

That was a really good blog post, however I am strongly against the following sentence:

"I think there’s a general consensus that @safe, pure and immutable should be default."

It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.

On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
> "I think there’s a general consensus that @safe, pure and immutable should be default."
>
> It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.

+1

The point of them not being default is that you can ignore them if you want, and create added-value instead of proving properties in your programs.

So a D program can start its life being crap and get better _if_ it creates any value.

On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
> On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
>> A few things that have annoyed me about writing D lately:
>>
>> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
>
> That was a really good blog post, however I am strongly against the following sentence:
>
> "I think there’s a general consensus that @safe, pure and immutable should be default."
>
> It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.

My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.

> this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language

How? Rust has immutable and safe by default and it's doing fine.

> this is completely against D's liberal philosophy where you can program however you want.

It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. @system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.

On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
> On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
>> On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
>>> A few things that have annoyed me about writing D lately:
>>>
>>> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
>>
>> That was a really good blog post, however I am strongly against the following sentence:
>>
>> "I think there’s a general consensus that @safe, pure and immutable should be default."
>>
>> It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.
>
> My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.
>
>> this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language
>
> How? Rust has immutable and safe by default and it's doing fine.
>
D and Rust are competing to get the C/C++/Java/Python market share. In order to do that they should make it simple for developers to convert to the new language. Due to its design, Rust is insanely hard to master, which on the long run I think will kill the language despite of the advantages it offers. On the other side, consider die hard C fans: they are willing to accept the possibility of a buffer overflow simply because they want more power. Do you honestly think that they will ever take D into account if @safe and immutable data will be the default?

>> this is completely against D's liberal philosophy where you can program however you want.
>
> It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. @system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.

It still is, because the user is imposed to work in certain conditions that some might not want to.

On Thu, Dec 13, 2018 at 10:29:10AM +0000, RazvanN via Digitalmars-d-announce wrote: [...]
> D and Rust are competing to get the C/C++/Java/Python market share. In order to do that they should make it simple for developers to convert to the new language. Due to its design, Rust is insanely hard to master, which on the long run I think will kill the language despite of the advantages it offers.  On the other side, consider die hard C fans: they are willing to accept the possibility of a buffer overflow simply because they want more power. Do you honestly think that they will ever take D into account if @safe and immutable data will be the default?

Why not?  You can opt out. It's not as though you're forced to use immutable everything and nothing but, like in a pure functional language.  Just tack on @system or mutable when you need to.

Some people balk at the idea of `mutable` being sprinkled everywhere in their code, but that's really just a minor syntactic issue. There's already precedent for using `val` and `var` -- it couldn't get easier to type than that. The syntax is not a real problem.


[...]
> > It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. @system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.
> 
> It still is, because the user is imposed to work in certain conditions that some might not want to.

No, there's always the option of opting out. There's no imposition. It's not like Java where everything must be a class, no matter what. You can write @system code or mutable variables to your heart's content.

The idea is to *default* to @safe so that when the programmer doesn't really care either way, the default behaviour gives you memory safety. Or default to immutable, so that unless the programmer consciously wants to mutate state, he'll get the benefit of being warned about any unintended mutation. Plus optimization benefits for variables that don't need to be mutable.  But defaults are called defaults because they're there to be overridden.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

On Thursday, 13 December 2018 at 17:07:58 UTC, H. S. Teoh wrote:
> [snip]
>
> Why not?  You can opt out. It's not as though you're forced to use immutable everything and nothing but, like in a pure functional language.  Just tack on @system or mutable when you need to.
>


Mutable might be a little easier since it applies only to variables and member functions. If @safe is the default, including for main, then any @system block in your program and you also have to make main @trusted or @system too.