On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via Digitalmars-d wrote:
> i really really hate immutable integer args, for example, and can't
> see any sense in doing it. that's why i wondered.

It might be a bit annoying for short functions, but in principle the function signature should be written for the user (document an encapsulated interface) and exposing irrelevant aspects of the implementation in the interface is "bad taste".

On Tue, 23 Dec 2014 08:26:15 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via Digitalmars-d wrote:
> > i really really hate immutable integer args, for example, and
> > can't
> > see any sense in doing it. that's why i wondered.
> 
> It might be a bit annoying for short functions, but in principle the function signature should be written for the user (document an encapsulated interface) and exposing irrelevant aspects of the implementation in the interface is "bad taste".
that's why we have `in` keyword, which clearly indicates that argument is "in only". making `in` default is breaking of my lovely principle of least astonishment.

On Tuesday, 23 December 2014 at 08:43:06 UTC, ketmar via Digitalmars-d wrote:
> that's why we have `in` keyword, which clearly indicates that argument
> is "in only". making `in` default is breaking of my lovely principle of
> least astonishment.

"in" is "const scope"... But signatures in D are too noisy. It is very difficult to avoid, so it is important to keep signatures simple for increased legibility.

I think "in", "out", "inout" and "scope "should go. Make all parameters that are by-value immutable by default. Make all parameters that are ref scope restricted and alias free by default. Add tuples. Add ways to express that parameters are used in dangerous ways ("escapable", "returnable"...)

> I think "in", "out", "inout" and "scope "should go. Make all parameters that are by-value immutable by default.

I agree with this. In more that could to be interesting if
compiler could translate "in"  to something like "const scope
ref"  when it is an array or heavy object. to save memory
allocation and ease the way to get some better performance.

On Tuesday, 23 December 2014 at 09:29:20 UTC, Ola Fosheim Grøstad wrote:
> parameters that are ref scope restricted and alias free by default. Add tuples. Add ways to express that parameters are

Actually, "alias free" by default might be a bit too much, maybe just add "restricted" and a mechanism where the compiler presents a warning if optimization was limited by not having a guarantee. Then the implementor can add restricted where it is needed to get better performance.

20-Dec-2014 20:39, Martin Nowak пишет:
> Just wondering what the general sentiment is.
>
> For me it's these 3 points.
>
> - tuple support (DIP32, maybe without pattern matching)
> - working import, protection and visibility rules (DIP22, 313, 314)
> - finishing non-GC memory management

- final decision on @property

-- 
Dmitry Olshansky

On 12/20/14 9:39 AM, Martin Nowak wrote:
> Just wondering what the general sentiment is.
>
> For me it's these 3 points.
>
> - tuple support (DIP32, maybe without pattern matching)
> - working import, protection and visibility rules (DIP22, 313, 314)
> - finishing non-GC memory management

Great idea to start a list! Shared semantics and improving multithreading also come to mind. -- Andrei

On 12/20/14 10:45 AM, Jonathan Marler wrote:
> On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
>> Just wondering what the general sentiment is.
>>
>> For me it's these 3 points.
>>
>> - tuple support (DIP32, maybe without pattern matching)
>> - working import, protection and visibility rules (DIP22, 313, 314)
>> - finishing non-GC memory management
>
> scope would be nice:)

That would be part of non-GC. -- Andrei

"Ola Fosheim Grøstad" " wrote in message news:gkhgxlioxkzmxbiazfwn@forum.dlang.org...

> On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via Digitalmars-d wrote:
> > i really really hate immutable integer args, for example, and can't
> > see any sense in doing it. that's why i wondered.
>
> It might be a bit annoying for short functions, but in principle the function signature should be written for the user (document an encapsulated interface) and exposing irrelevant aspects of the implementation in the interface is "bad taste".

Making value parameters immutable, and therefore making the fact that they're not modified inside the function visible externally, _IS_ "exposing irrelevant aspects of the implementation in the interface".  The caller doesn't care what you do with them. 

On Wednesday, 24 December 2014 at 07:44:21 UTC, Daniel Murphy wrote:
> Making value parameters immutable, and therefore making the fact that they're not modified inside the function visible externally, _IS_ "exposing irrelevant aspects of the implementation in the interface".  The caller doesn't care what you do with them.

No. Make value parameters immutable, period. No mutable version as an option. This does not expose anything to the caller.

If you want a mutable version in the implementation, do so in the function body. If you only refer the mutable version in the function body then the overhead will be optimized away by the backend.