Revised RFC on range design for D2

[superdan]

Yigal Chripun Wrote:

> Andrei Alexandrescu wrote:
> > Yigal Chripun wrote:
> >> Andrei Alexandrescu wrote:
> >>> Yigal Chripun wrote:
> >>>> Andrei Alexandrescu wrote:
> >>>>> Yigal Chripun wrote:
> >>>>>> Andrei Alexandrescu wrote:
> >>>>>>> Yigal Chripun wrote:
> >>>>>>>> Andrei Alexandrescu wrote:
> >>>>>>>>> Yigal Chripun wrote:
> >>>>>>>>>> Benji Smith wrote:
> >>>>>>>>>>> Andrei Alexandrescu wrote:
> >>>>>>>>>>>> I stated two principles of language design. They could be
> >>>>>>>>>>>> true or
> >>>>>>>>>>>> false. They are up there for debate. They are subjective,
> >>>>>>>>>>>> because
> >>>>>>>>>>>> aside from some basics, language design is subjective.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The principles are:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) A language should minimize the number of syntactic
> >>>>>>>>>>>> constructs
> >>>>>>>>>>>> that
> >>>>>>>>>>>> are semantically and/or pragmatically meaningless.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2) The more frequently-used constructs should be given
> >>>>>>>>>>>> syntactic
> >>>>>>>>>>>> priority over the less-used constructs, particularly when the
> >>>>>>>>>>>> latter
> >>>>>>>>>>>> are also at risk of breaking the first principle.
> >>>>>>>>>>> I'd like to propose another principle of language design:
> >>>>>>>>>>>
> >>>>>>>>>>> 3) Consistency -- The expression of a semantic construct should
> >>>>>>>>>>> always
> >>>>>>>>>>> use the same syntax. Likewise, multiple uses of the same
> >>>>>>>>>>> syntactic
> >>>>>>>>>>> constructs should always result in the same semantics.
> >>>>>>>>>>>
> >>>>>>>>>>> Based on that principle, I'd argue that function-calling should
> >>>>>>>>>>> either
> >>>>>>>>>>> always use parentheses, or it should never use parentheses.
> >>>>>>>>>>>
> >>>>>>>>>>> Requiring parentheses for some function calls, but not for
> >>>>>>>>>>> others
> >>>>>>>>>>> violates the principle of consistency.
> >>>>>>>>>>>
> >>>>>>>>>>> In my prioritization of language-design principles,
> >>>>>>>>>>> consistency is
> >>>>>>>>>>> more
> >>>>>>>>>>> important then syntactic economy.
> >>>>>>>>>>>
> >>>>>>>>>>> Based on those principles, I believe that the parentheses
> >>>>>>>>>>> should be
> >>>>>>>>>>> mandatory for all function calls.
> >>>>>>>>>>>
> >>>>>>>>>>> --benji
> >>>>>>>>>> I was about to post a very similar post (it's still in my drafts
> >>>>>>>>>> folder)
> >>>>>>>>>> besides fully agreeing with the above, I'll add the following:
> >>>>>>>>>> operator & in D is not consistent.
> >>>>>>>>>>
> >>>>>>>>>> int x;
> >>>>>>>>>> auto y = &x; // y is int* (i.e pointer to int)
> >>>>>>>>>>
> >>>>>>>>>> int func(int);
> >>>>>>>>>> auto f = &func; // consistent with the above:
> >>>>>>>>>> // f's type is - int function(int); i.e function pointer.
> >>>>>>>>>>
> >>>>>>>>>> let's try a class:
> >>>>>>>>>> class Test {
> >>>>>>>>>>   int x;
> >>>>>>>>>>   int func(int);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> auto test = new Test();
> >>>>>>>>>> auto y = &test.x; // consistent with the above
> >>>>>>>>>> auto g = &test.func; // this is inconsistent!
> >>>>>>>>>> in the above g is a delegate which is not a function pointer.
> >>>>>>>>>> just as int* is different from int[]. you wouldn't expect to
> >>>>>>>>>> get an
> >>>>>>>>>> int[] in the above, would you?
> >>>>>>>>>>
> >>>>>>>>>> a more consistent approach would be to have:
> >>>>>>>>>> - func and obj.method to be treated as delegates, of course for
> >>>>>>>>>> function
> >>>>>>>>>> pointers there should be an implicit cast to delegate.
> >>>>>>>>>> - &func and &obj.method would be strictly function pointers.
> >>>>>>>>>> - using parentheses is mandatory for function calls.
> >>>>>>>>> A delegate /is/ a function pointer, more precisely, a pointer to
> >>>>>>>>> function packed with a pointer to a value.
> >>>>>>>>>
> >>>>>>>>> This also seems to reveal a lack of understanding of how class
> >>>>>>>>> methods
> >>>>>>>>> work. What function would you make &obj.method point to?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Andrei
> >>>>>>>> I understand a delegate as a struct of two pointers as you said so
> >>>>>>>> yourself, above. an int[] != int* and so does a delegate != [C
> >>>>>>>> like]
> >>>>>>>> function pointer.
> >>>>>>>>
> >>>>>>>> I'd make &obj.method to be the function pointer stored in the
> >>>>>>>> delegate.
> >>>>>>> What is the signature of that function?
> >>>>>>>
> >>>>>>> Andrei
> >>>>>>>
> >>>>>> say we have:
> >>>>>> class Test {
> >>>>>>   int method(int);
> >>>>>> }
> >>>>>>
> >>>>>> auto obj = new Test();
> >>>>>> auto fPtr = &obj.method;
> >>>>>>
> >>>>>> type of fPtr would be: int function(int); or in C syntax: int
> >>>>>> (*)(int);
> >>>>> That doesn't stay glued. What is "this" inside the function?
> >>>>>
> >>>>>> are you asking because of C++ pointer-to-member-function types?
> >>>>>> in C++: int (Test::*)(int); ?
> >>>>>>
> >>>>>> You know C++ much better than most of us here (certainly better than
> >>>>>> me), in your experience, is that distinction useful?
> >>>>> C++ pointers to member functions aren't that well designed. But at
> >>>>> least
> >>>>> they work :o|.
> >>>>>
> >>>>>
> >>>>> Andrei
> >>>> if I understand it correctly, in C++ the type of this is encoded in the
> >>>> signature (as above) and you use obj.*pointer(..); to call the
> >>>> function.
> >>>> this is a possible solution (using the C++ pointer to member function).
> >>>> however, maybe we should use a more python like solution:
> >>>> the signature becomes: int function(Test, int);
> >>>> and this refers to the first argument (just like you pass the "self" in
> >>>> Python).
> >>>>
> >>>> I think i prefer the second option more [ int function(Test, int) ] and
> >>>> it will be easier to use in C.
> >>> It's great that you are now equipped to appreciate the advantages and
> >>> disadvantages of various tradeoffs. Maybe a reevaluation of the existing
> >>> solution would be useful.
> >>>
> >>> Andrei
> >>
> >> my main issue was with the syntax. and I still think it's inconsistent.
> >>
> >> the only drawback I see with my suggestion is the need to implement this
> >> additional feature with method pointers.
> >>
> >> it adds consistency for the common case (delegates) without limiting any
> >> of the current uses.
> >>
> >> What other cons do you see for my suggestion besides the difficulty to
> >> implement?
> > 
> > I think we're better off with the current state of affairs.
> > 
> > Andrei
> 
> so if I understand you correctly, you don't see any other disadvantages.
> so it all comes to whether it's worth the time to implement this, on
> which we appear to disagree.
> 
> since I'm unable to convince you that [from my POV as a user] it's worth
> it, I won't write more about it.
> 
> Thank you for your time discussing this issue.
> Yigal

way i read it he was tryin' to save you face, but of course you missed that too. just continued making a fool of urself. nothing personal dood. but really u r in a mismatch here. first u make a "proposal" that makes no sense. you can't as much put two and two together in a function sig. the man is patient kind enuff to explain. here you're wrong here you don't make sense here you're talking outta your ass. did you my friend miss a beat. hell no. no ``thank you i'll go study some more'' no ``sorry you was right i was wrong'' no ``let me correct myself'' not even effin' ``oh ok''. wtf man. r u really only mouth and no brain. then who's cocky and holding his tail up. ``so if I understand you correctly, you don't see any other disadvantages''. oxpoop. there are no advantages, that's the problem. poop.