December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | 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".
|
December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad Attachments: | 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.
|
December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | 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"...)
|
December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | > 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.
|
December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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.
|
December 23, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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 |
December 24, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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
|
December 24, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan Marler | 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
|
December 24, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | "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. |
December 24, 2014 Re: What's missing to make D2 feature complete? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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.
|
Copyright © 1999-2021 by the D Language Foundation