Lesser and greater signs never were a good choice. They were chosen because
of C syntax restrictions. Go creators would do *slice[T]* (or may be just
*[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind. Because,
if you have managed not to notice it, Go barely inherited anything from C.
Know why? Because C is full of unfortunate decisions. Some people love it
because this is their first relatively low level language and they like the
power. Me, who wrote assembler before C, have never been impressed with it:
its syntax is not particularly pleasant to read and I rather felt the lack
of power with it. It is not only hard to read, it is just plain weird.
Consider this:
a * b;
What is this? May be an expression? Or a declaration, pointer a of type b?
So, please stop using languages with syntax inherited from C as a
benchmark. The C is a result of the lack of planning, a chaotic
development. And this usage of comparison operators as brackets is an
unfortunate combination of circumstances.
Luckily, there was a planning in Go, with some initial limitations which
causes a bit of pain nowdays, still much better than C and even more so
than C++. I am really glad they don't consider these <<<<< monstrosities: I
tried Scala and as much as I dislike the language in general their []
things for generic parameters left very good impression. I really like they
borrowed the idea.
четверг, 23 июля 2020 г. в 00:22:26 UTC+3, sah...@naman.ms:
> With angled brackets, do we really need the colon or dot on both sides?
> Wouldn't it be enough to just have it on the left to eliminate the parse
> time ambiguities? Like f<:int> or f<.int>?
>
> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой, <eugene....@gmail.com> wrote:
>
>> Maybe something like this:
>> using <.Type.>
>> func f(T<.int.>)
>> struct{ T<.int.> }
>> interface{ T<.int.> }
>> []T<.int.>{}
>>
>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
>>
>>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba <faifa...@gmail.com>
>>> wrote:
>>>
>>>> I'd say a dot is necessary when instantiating a function call but
>>>> unnecessary when instantiating a type because it's always syntactically
>>>> clear when a type is required.
>>>>
>>>
>>> That's not true in Go. Conversions look like function calls:
>>>
>>> y := f(x)
>>>
>>> could be a conversion or a function call, depending on whether f is a
>>> function or a type. If you need to use type parameters on f, the same
>>> parsing problems present themselves whether it's a parameterized type or a
>>> type parametric function.
>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f5e27f11-3dc4-4caa-adc4-4f4619a50cfcn%40googlegroups.com.
